Moa

stallturn.com does not disable it (I use it for working on my mods to LEAVU2 while running EFA and VNAO mods) as it is not big on human vs human air-to-air engagements. I'm sure there are other servers that allow it too, but you'd have to use trial and error to find them. However, the popular servers (104th, 51st, 3 Sqn, Akado, etc) currently do not allow non-standard export scripts. There is a proposed project to adapt LEAVU2 to be more palatable for these servers. It is a hard call to make an expensive purchasing decision based on this. Your gear would always work on single-player so that is one reason to get it. The question is if and when the 'big' air-to-air oriented servers will ever permit (standardized) data export scripts (note, this is data for your aircraft only and is not the same as 'global exports' for things such as TacView). People are afraid of non-standard exports scripts for your own aircraft as it may give the F-15 the ability to range HOJ shots (which is of course something the MiG and Flankers can already do using the Berezoya RWR, but somehow this is not permitted for the Eagle). Many people's home cockpits don't work at the moment on the big servers so ways are being sought to enable these (which would also make your MFDs and touchscreens work too).

Please also note that the (freshly-minted) version 1.3.0 of the lottu utility also supports TacView during track playback. http://forums.eagle.ru/showpost.php?p=935775&postcount=22 Download lottu 1.3.0 for Windows (requires Java) directly from: http://www.stallturn.com/wiki/upload/2010/4/lottu-1.3.0/lottu-1.3.0.exe Other versions can be downloaded from the lottu homepage at: http://www.stallturn.com/wiki/en/lottu

lottu 1.3.0 is now available. It includes: * Option to enable and disable TacView playback (that is, global data exports) from the lottu GUI. [suggested by Fahhh] * Better handling of non-standard LockOn installation locations. The track and player (simulator.exe) locations last used are remembered using a preferences file stored in the user's home directory. [suggested by Crunch] Credits (suggestions and testing): * 104th_Crunch * 104th_Rock * 2IAE_Fahhh Lottu 1.3.0 for Windows can be downloaded directly from: http://www.stallturn.com/wiki/upload/2010/4/lottu-1.3.0/lottu-1.3.0.exe JAR files for Windows, Mac, Linux can be obtained from the lottu home page at: http://www.stallturn.com/wiki/en/lottu http://www.stallturn.com/wiki/upload/2010/4/lottu-1.3.0/lottu-1.3.0.jar Note: The first post has been updated to link to this latest version of lottu.

Thanks Wags and team. We appreciate the pre-release information you are giving. Even if it later turns out the actual product may have to have features re-scheduled for later in the DCS series it is still nice to know the direction Warthog is heading (eg. knowing mission generation is coming means the community doesn't have to re-invent the wheel). Have a good trip.

Funny you use the word 'laser' GGTharos. That is exactly how I've heard it described by publically available written reports from Warthog pilots. The drop is relatively minimal apparently 10 feet at 4000 feet range (2/3 nautical mile), and with a high rate of fire and tracers it would look a bit like a straight beam from the cockpit. Maverick problems are also reported in the following thread: http://forums.eagle.ru/showthread.php?t=53930

Would be nice if EDM was documented. Then we can get the Blender crew to write converters for it. Otherwise people have to choose between either infringe copyright or purchase expensive software just to contribute meshes to LockOn. I don't believe in infringing copyright so won't go that route, but don't want to plonk all the cash down for 3ds Max 2010 either - not when there are TM:Warthog sticks and MFDs to buy instead and Blender is perfectly good. All it takes is a little documentation about the file format.

Yes, I have noticed this regression too. Makes using the A-10A hard when you want to quickly lock a SAM before going defensive. This (bad) behaviour occurs consistently, it is not a transient thing.

Please contact Symantec and ask them about this problem (you paid them for the product, so they have to provide you with support). There are no viruses in the lottu version obtained from the stallturn link.

If money is tight you could look at an AMD AM3 system. The AM3 will last more years than an Intel motherboard, which means you can get a budget CPU now and upgrade to a Phenom II x6 1090T when you get a chance (which has great performance and performance-per-dollar, which matters since your budget is limited). Depending on your memory you may be able to re-use it.

Amen. DCS is the best sim.

One thing I should mention that the Java world does bring is Test Driven Development (TDD) and tool support for it. Yes this can be done on C++ but it requires a team with exceptional discipline to do it - and it is even harder if you have a legacy source code base to write coverage for. For me using TDD is about time and money. It doesn't remove all defects but gets you much further down the exponential-decay curve of bugs remaining in code than manual testing. Plus the test automation means you're not afraid to do testing (issue a command instead of days of manual labour running tests, checking results, fixing, re-running the tests ...). You're also not afraid to add enhancements as you notice and fix regressions immediately. I worked on a long-term high-performance C++ project and know all about the paralysis mode where adding features gets very hard and you avoid doing sweeping changes since it is so risky. Of course LockOn is an interactive GUI system which makes it hard to test some parts of it. However, it is an 'iceberg' in the way that some code is dedicated to rendering but far more is submerged and not directly visible to the user. Those parts that can have test automation applied ought to. It will save time, money, and developer frustration. Expensive human tester time ends up dealing only with the interesting cases - not the routine stuff. I have no pecunary advantage in suggesting Java and Test Driven Development. I'm just trying to impart some wisdom from the trenches - since the State of the Art in reliable software development has moved in recent years. It's also that as a consultant developer myself LockOn seems to have many simple bugs that could easily be fixed by adopting a TDD process, and seems to be hard to adapt for multi-core (which is one of the principal reasons I suggest new standalone parts be developed in Java). Once you start using these processed working any other way seems like you were a craftsman in the Dark Ages - even if TDD needs to be applied judiciously and is not a panacea for all developmental issues. I appreciate how hard it must be for the ED team to get stuff going and keep it going as new features are added. It would be nice if new features could be added without too much pain (cost) to ED and in a reasonable time (to placate the unreasonable users :)).

Your statement was correct until the middle of the last decade (for server-side/plain Java). Client-side Java was not as good until Java 1.6.0_u10, then all drawing became hardware (shader!) accelerated. That is not to say you don't have to be careful performance-wise with Java, of course you do, but Java is now faster single threaded than C++ and very much faster when used multi-threaded (which is used far more often than C++, much makes it faster). Java is the sensible strategic choice for new projects for the reasons in my earlier post (better tools, more libraries yada yada). Please read the following reports, including the INRIA supercomputing report that says Java is faster than C++, C (!) and approaching FORTRAN (which is fast since it is so simple). The Java libraries aren't so good for intensive networked applications (eg. scientific simulations) but LockOn is using a very slow 128/64 kbs for most clients which is sloth-country in comparison. http://hal.inria.fr/inria-00312039/en http://www.facebook.com/note.php?note_id=24763131623 http://kano.net/javabench/ Also note that IL2 is largely written in Java. This eased porting it to the PS3 where it could tap into the large market of consoles. Like I said, Java is a sensible (safe) strategic choice, and you can always degrade to JNI (or the even easier JNA) when necessary (mostly for specialised hardware support). I used C++ for a decade. Then I used Java for a decade. I know which I prefer to write my applications in. C++ made perfect sense when writing LockOn no doubt at the time. If you are writing new stuff from scratch I don't think limiting yourself to C++ on Windows 7 makes business sense when you could tap far more platforms than that. After all, why support a declining 89% of desktops and ignore consoles when you could deploy to 100% of desktops, and also consoles [compile Java to native using gcj for them] and the smarter phones (which are becoming powerful and have OpenGL ES hardware). Yoda: You are completely right. The problem with 'Java' is not the language but the too-many-layers-of-abstraction libraries written by CS graduates who think that more layers of indirection == better. Write stuff youself and you don't have the problems.

Yes. This makes sense to me. The following could be performed on the server: * weapon guidance and hit detection scheme server-side (printscreen cheat on clients would not affect missile impact). * enforce weapon guidance only locked targets or those the pilot is looking at. * since a second machine is involved the missile guidance calculations could be made far more realistic than at the moment. * basic fuel, countermeasures, and stores caclulation performed periodically server-side. * flight path checks, no more clients moving at Mach-25 and pulling more. If it was written in Java (yeah, I'm a pusher, but only 'cause it is a good drug) then you would have: * Host anywhere: Windows (32- or 64- bit, any version from 2000 onward, without recompile!), Linux, Mac etc. * Good multithreading support (C++ resource management with threads is just too hard to get right). You get to use all 6 cores dual-threading on that lovely Phenom II x6 1090 T you just bought. * Users can use free tools without restriction (don't have to buy or steal IDE and SDK like .NET Windows tools). * Get to use all the good existing libraries (log4j, JUnit, Spring, Metro etc etc) without re-inventing the whole stack from scratch. Java has great built-in libraries but the 3rd party stuff cannot be paralelled in scope. * Produce TacView-like output server-side only which is later streamed to clients. * Stop the flamewars over whether and how much Integrity Checking to use - it would no longer be necessary to perform IC. The only thing holding us back is knowing the network protocol of LockOn, otherwise we could produce such a thing and it would scale to many users and more complex battles than we have now. Unfortunately the packet protocol is undocumented :( There are those who argue that weapon collision detection cannot be performed on the server due to lag. Well, the 'truth' has to be determined somewhere and the server is the only trusted and shared place to do it. Plus, the server has a single consistent view of the battle, rather than each client having a slightly different view due to lag. Sure the client will have visual cues that are slightly different from the server's picture, preventing last minute G pulls to avoid missiles, but that is not such a bad thing and you can still think you have dodged fire due to what you see on screen but still die (although usually this is more likely with very low-flying and ground collisions). Since the server wouldn't be running graphics it would do a better job than any client. The other things about not requiring graphics means that the any of the large number of game hosting services can be used to serve a game. At the moment it is very expensive to provision an appropriate server with a good connection since a rackmount is desirable (co-locations like these) but most rackmounts don't come with video cards. In the USA it is not a problem to get these but elsewhere (bordering Antarctica like me) this is an expensive hassle. If you throw in a server that can be run on Linux (as well as Windows, of course) then someone doesn't have to pay the Microsoft Tax to host. You would see a lot more LockOn servers out there as a result. So, the question about dedicated servers really boils down to, is it possible to get or reverse engineer the LockOn client-server protocol? Will ED be so kind as to document this for us, so we can do the rest?

'Mission warm-up' as has been suggested will help stutter on the server but not on clients. When spooling as a client you can see the hills get rendered with progressive levels of detail as more stuff gets loaded in (very clever by ED). However, there is stutter (due to disk IO probably) as this happens - and during loading of new textures and effects for kills etc. As each client stutters it will cause stutter in their network replies to the server (in software not fully threaded). It used to be the case in FC 1 that a long lag in reply could cause problems in the server as it struggled to cope with bad/missing client packets (sometimes such packets were noted in the network log IIRC), occasionally there would be a null pointer caused somewhere which would kill the server. I'm guessing this may still be the case. If so, then that can only be fixed by ED I think - handle all cases of bad/missing network data without letting a null pointer slip past.

Yes, Saitek are always that bad. They wear out far faster than a Thrustmaster (which requires some maintenance) or CH (which rarely wears out at all).

Yeah, Jack's skins are superb - both for the F-18 and F-14. They are part of a VNAO FC2 mod that has not yet been released - I'm hoping it will be soon (well, I've been trying to push for it :)).

CyBerkut, I think the original problem Vyrtuoz was solving was that the end of file might not get written yet you still wanted to recover the TacView. What would work is if the TacViews were encrypted and the public key was not made available for several minutes afterwards. Unfortunately, it is trivial to bypass this in the Lua export file - the data would need to be written encrypted in compiled code. If your machine crashed before the key was written you wouldn't be able to read the TacView - which puts you back at square one.

As good as TacView is, it does produce a lot of data that needs to be streamed to disk. This can induce stutter in clients. TacView should not be running on a server as the disk I/O can result in network lag (the PC architecture has never been great for this). Disk write activity without write caching can be a major source of lag. The downside of write caching is that data (such as your local mission track) is lost in the event of a crash. Incidentally, I've been mucking around with LEAVU2 and it streams a few hundred bytes a dozen times a second between your (local) LockOn instance and LEAVU2 (mostly running on the same machine, but could be on your LAN). The network usage here is 2 kB/s tops. If it is on your machine then the time taken is 2 kB over your multi-gigabit bus speed. Depending on the driver details, zero-copy shared memory could be used. Even if you are streaming the data to another box on your LAN (as I do) this is 2 kb/s over a Gigabit link. The bandwith used is 0.002 % of capacity (0.02% if you have a 100 Mb/s connection). In short, the local LEAVU2 traffic is negligible and does not contribute to client lag in any way. It doesn't contribute to server lag either since the data for LEAVU2 is sourced from data you local LockOn client already has. I hope those numbers put the LEAVU2/ERI issue to rest with respect to alleged lag - use science not superstition please.

I was the one who suggested to Yoda that he used Java. Please note that Leavu2 does use a little C++ via the Java Native Interface (JNI) on Windows (not used, or needed, if you run leavu on Linux or a Mac). Pros for Java: * Very large standardized libraries. * Multi-threading simpler and better supported than in C++. * Excellent tools available (eg. NetBeans + Profiler, JUnit, JVisualVM etc). * Much faster to develop. * Portable (matters for me since I develop/use on Linux, Mac and Windows). Also works no matter what Windows version you are using, which C++ does not always do. For me, .NET is a non-starter as it is platform-specific and has lifecycle issues (parts of the platform are deprecated quite quickly viz Java). * Interfaces with OpenGL via JoGL, which is also portable. * It is easier than C++ to write code with fewer subtle bugs (garbage collector essential in multi-threaded environment, otherwise it's hard to know which thread 'owns' a pointer's memory). * It has a very good compiler. Besides the fast code produced in recent years it also helps you find a lot of bugs at development time (which LUA is good for quick-and-dirty stuff the fact the compiler can't help you means you have to find bugs yourself by running the application over and over and over again - very painful and slow, and most regressions or bugs don't get caught). * Java was developed to be secure. Java code does not get exploited locally nor remotely. * The tools, development kits, documentation, resources, examples etc etc are all free - both in the sense of no cost ("free beer!") and open source (liberty). * There are alternate implementations. You can use Sun's (now Oracle) JDK, IBM's JDK, GNU GCJ + Classpath (compile to native if you need to). Java is not going to go away. In contrast, .NET will be changed, morphed, dropped at the whim of a single company - and in fact .NET projects must be incompatibly changed on a regular basis so Microsoft can derive revenue from upgrades. * Because Java has runtime Just-In-Time compilation it can often run faster than statically compiled languages (C++). The French scientific supercomputing branch of INRIA published a paper on this a few years back, and Java has got even faster since then. Cons for Java: * Can be very performant, but you must profile your application to remove any bottlenecks. C++ is generally performant without effort. Some of the reduced development time for using Java is spending making your app run faster (in C++, you would instead spend the time finding pointer bugs). * Can't use platform-specific features unless use JNI (Yoda needed this so that windows accept input but don't steal 'input focus' from LockOn). * Clients require a JRE installed (nearly everyone has this already, so not a big issue these days). * Used to be slow to start, although the Java Quickstarter in Java 1.6.0_u10 and later makes a big difference. * Some libraries are slow eg. text rendering in JoGL is relatively slow (don't want to do it at 60 fps) so you need to cache textures and remember state to avoid re-rendering unchanged panels. * People still have a perception that Java is ugly, bloated and slow. This has not been the case for years, but it is hard to convince some people whose knowledge has not been refreshed from half a decade ago. * People confuse Javascript (a bit flaky) with Java. Not the same. So, Java is not perfect (and C++ also has its uses) but unless there is a very good reason to select another purpose-specific language it should always be a contender for new applications. Now, back to your regularly scheduled programme ...

You cannot win by staying purely defensive - your enemy just gets closer and closer improving his hit chances with each shot. If you have an active missile try and launch a missile before your enemy does. You can do this flying at low level. Support it as long as you can before going defensive (read the manual about the F-15's missile countdown timeer). Even if you don't get him he'll go defensive for a bit by which time you should be ready to re-engage.

F-15 and F-16 are a 'high/lo' mix. F-15 excellent for air-to-air but too expensive to have hordes of them. F-16 good, but not as good in air-to-air, but cheaper. This makes up the numbers so that the US Air Force is not outnumbered in a strategic sense. The F-16 also performs many missions (A2G, SEAD, naval strike) that the F-15 was not originally designed for, or too expensive to risk. The F-15E is there to keep the F-15 relevant when there are no A2A engagements to be had (otherwise it gets hard to justify the expense of the F-15 when they don't get used). US strategy contines this mix. A few expensive F-22 and more numerous F-35 in greater numbers. The Russians also adopted this philosophy to some extent. The more expensive Flanker supplemented by cheaper (but still able) MiG-29. One is better than the other as a specialised design. However one is better than the other in cost, numbers, and general-purpose utility.

With LOTTU you must select a track and the path to the player, called "simulator.exe" (if you've installed LockOn in a non-default directory). Thanks Crunch for letting me know of this.

You can use LEAVU2 on the same screen and computer as LockOn. In this case you'll need to run LockOn in a window (not full-screen) to see the display. You can also run LEAVU2 on the same computer but on a separate screen (multi-monitor setup). The last (and best option) is to run it on a separate computer. You could even use multiple computers if you have them lying around - including Macs and Linux boxes (it's Java after all, you just need a platform that supports the JoGL OpenGL 3D libraries). I should finish the AoA control this weekend and as part of this I was hoping to package LEAVU2 into a nice executable and ModMan package this weekend. I'm in discussion with Yoda about this. Hopefully it'll save users some effort in installing/upgrading/uninstalling.

Mastiff, it's not money that counts it is time. If I had the time I'd be working on a F-16 and F-18 pit (the same technique can be used for both). By pit I don't mean textures, I mean working MFDs and clickability - using the LEAVU2 framework. Am currently working on some small controls for F-18 (Angle-of-Attack indexer) for LEAVU2. Not much time since I want stats to be finished next month (I have to play 'hooky' from stats to work on stuff like cockpit controls). One day (later this year, after stats and mission generator/dynamic campaign) I'll get around to doing those pits to my level of satisfaction.

Coolts, it's gratifying to see you thinking (sadly, not everyone does this). Modern tactics have fighters and attack aircraft operate in pairs or multiples of pairs. Historically (by the Luftwaffe during the Spanish Civil War) this was found to be more effective than a trio and vastly more effective than a lone wolf (who simply can't scan enough sky in defense and also attack effectively). Bombers, transport helos and transport aircraft do operate singly. If you can, team up with a like-minded soul or even an existing squadron while flying. It is a completely different experience. Please don't start the "beauty contest" debate about servers. Perhaps the 104th is "plain vanilla" enough to suit many people's tastes. That leaves servers such as 51st and 3sqn free to experiment with other scenarios that suit other tastes - which they do extremely well. The overall number and variety of missions and servers within the community would seem to be a far better goal than the relative (and ephemeral) popularity between individual servers. So, please don't start feuding.