Moa

Thanks Sharkster64.

Even if they were criticism, they'd still be welcome.

Interesting points Case. Thanks for taking the time to make them.

Thanks for the link and instructions 51st.

Thanks for your comments Case. It should be fixed, you accessed it while I was doing an update (it's still a beta so gets fix and enhancement updates all the time at the moment). Sorry it was down just as you were accessing it. Since you asked, the reason I use Java is that I personally hate page refreshes for doing simple things. When the number of players gets large (previously around 1000 per month on the 104th) then continually clicking through pages irks me. With Java you can move the columns around (drag n drop), remove some columns (see the icon to the right of the columns on the a2a and a2g pages), sort any column simply by clicking on it and the sorting doesn't require a page refresh, resize windows (especially useful when looking at the various pilot summary pages). You can also use the search and filtering functions to find a pilot that matches a string or show only the pilots that match a string (eg. only display the 51sts pilots on the a2a or a2g pages). All of this also happens on the client's CPU and memory, which means that the system scales to a larger number of simultaneous users all 'dynamically' manipulating their views in near real-time (dynamically changing) - hence the name of the software. "Near real-time" means if you perform an action and click an update button within a few seconds you should see your score change and the details of the event. I wasn't interested in PHP as it requires continual page refreshes and what you can do with a page (dynamic resizing) is limited to what HTML can do - which is a far bit shorter of what you can do in an applet. I tried very hard to do AJAX using the Google Web Toolkit. It is the best AJAX toolkit by far (IMHO) but is still vastly short of the capabilities of an applet. Unfortunately, applets can be problematic (especially as I work through the teething issues - but should settle down very shortly). Thanks once again for your comments. They especially mean something from you given the huge amount of work you did and do with the nice 51st stats pages - you know exactly what it is like getting this stuff going. The slow loading of the pages is very unlikely to be due to Java. Java is faster than C++ and C these days, and pretty close to FORTRAN for raw speed. All the graphics are fully hardware accelerated (as much as possible on the client's machine, unless they have a poor graphics card that is doing software rendering, eg. some Intel chipsets). Most likely it is network bottlenecks (possibly at my end given the number of people accessing it) and the large amount of information being transferred (there are an awful lot of per-pilot statistics that get sent when a pilot selects their page). Incidentally, as I've mentioned before the dynamicscore software makes its statistics fully available though a SOAP webservice. You could use this to get the stats for the 51sts pilots (or anyone else) and merge them with the 51st database. I may also use it to make HTML pages for those platforms that can't use applets (damn Steve Jobs and his decision with the iPhone). The WSDL for the VNAO stats are at: http://stallturn.com/dynamicscoreweb/DynamicScoreWebService?wsdl The WSDL for the 104th stats is at: http://stallturn.com/phoenix/DynamicScoreWebService?wsdl You an use SOAPUI (http://www.soapui.org/) and point it at the WSDL to see the supported operations. In the future I may make a REST webservice interface to complement the SOAP one, as that may be easier for some people to deal with (and bookmarking etc will work with it). Edit: While James Gosling is hardly an unbiased commentator regarding Java performance he has a link to a report from INRIA (French research institute) where they analyze Java for supercomputing work and conclude that it is faster than C and nearly as fast as FORTRAN - although networking could be improved. This was back in 2008 and Java has had a lot of optimization since then (eg. all of Java2D is now hardware accelerated using DirectX or OpenGL shaders, if available). Please refer to: http://blogs.sun.com/jag/entry/current_state_of_java_for

It does take a while. My own experience I got a sore neck and shoulders until I realized not to tense up so much while trying to point the TrackIR. Once you are used to using a TrackIR you cannot go back - it is definitely a 'game changing' technology.

It is likely to be your network connection (transferring the score data) or computer (rendering that data) that is slow. Unfortunately I can't help with these.

Thanks Pilotasso. This is actually a bug in the source LockOn logs where gun kills don't always specify the weapon used (the Ka-50 is affected more than anything else as it does a lot of gun work) in the LUA callbacks that the user (eg. the 104th stats system) can hook into. I do a lot of work by tying together several log entries to work out what weapon was used but sometimes it is ambiguous - so I have to mark it as unknown. I'll be looking closely at this to see if it can be improved. ps. There is a thread on the 104th forums dedicated to bug reports (see earlier post on this thread). It is more convenient if you report them there.

Wow Jack. Really stunning. Will these work with the VNAO Hi-Res skin pack? or are they a replacement for it? In addition to the RAAF 20th Anniversary skin is there also a RAAF 3Sqn low-viz skin? Thanks for your hard work. As a reward, if you don't have it already, here is a photo from one of the VNAO guys taken a few weeks ago that works as a Air Traffic Controller at NAS Fallon (home of TopGun), currently my MacBook Pro desktop background: Awesome that your topmost skin matches this. Here are some ideas for skins too (some of which you've already done) http://xplanefreeware.net/barry/index%20F18.html

> I have tested in Chrome, IE9 and FF and all 3 give similar performance for me using the latest Java. Thanks for the info Crunch. This is expected. The 104th stats use a "Java applet" rather than JavaScript running in the browser (they have similar names but are quite different beasts). JavaScript is notoriously slow on older versions of Internet Explorer. If anyone is interested I can make the stats program as stand-alone application you run from your desktop (using the very nifty Java WebStart technology, no source code changes reuqired :) ). Might be easier for those with browser issues.

TrackIR 5.1 (beta 2) software released, with 64-bit support TrackIR 5.1 (beta 2) software released with 64-bit support (good for A-10C!). For relevant details (and any comments) please refer to this thread (in the hardware section of these forums): http://forums.eagle.ru/showthread.php?t=63957 Apologies in advance for the re-post with link, thought it might be *very* relevant for A-10C users who might not see the hardware thread.

Good for those wanting to use 64-bit DCS:A-10C (hopefully the next beta might work with the new TrackIR software). http://www.naturalpoint.com/trackir/06-support/support-download-software-and-manuals.html

Hiya all, and thanks. If you get a blank page in Java simply restart your browser and you should see it. Should work with any Java 1.6 version (although I recommend at lest 1.6.0_u10 for hardware accelerated rendering, and 1.6.0_u22 contains a security fix for applets). I originally wrote it in the Google Web Toolkit (http://code.google.com/webtoolkit/) but even with a fully AJAX interface it was a pain to sort columns and resize windows. So I switched to an applet (I considered the downside of requiring a plugin to be less than the upside of a fully 'dynamic' interface). The real dynamic bit is that the stats update in near-real time (if you keep hitting the update button). You should be able to resize windows, sort columns by clicking on them, and use the callsign find and filtering (only show matching callsigns) functions without requiring a fetch from the server (or another complicated page with sort and search criteria). There are a lot of tooltips in the interface to explain some stuff. The software is still beta (a couple of corner-case bugs) and being actively worked on. The intent is to share it (and the source code) with everyone once all the bugs are fixed and current set of enhancements are done. The installation is a little complex but it uses very little CPU and I/O resources (you can run it on the game server easily - as I run several copies on stallturn). There is also a 'SOAP webservice' interface that allows you to get the stats without using the GUI. You could do several things with this: * squadrons can exchange data. * You could build a customized non-Java applet interface (eg. GWT, JSF, ASP or whatever you liked) but use the 'heavy lifting' of the dynamicscore2 stats back-end. * The 51st can preserve their investment in their nice stats system but still access data about its pilots from servers running dynamicscore2. Enjoy, and Merry Christmas guys.

Good work Crunch.

Nice one Konkussion. The more servers the better.

Generally you use rudder: * When maneveuring on the ground. * During your take-off roll to keep you on the runway; likewise when landing (eg. once Nose Wheel Steering re-activated). * When performing turns. * When performing aerobatics (no stall-turn without a rudder!). * When performing crosswind landings. * Correcting for yaw if you lose an engine (using rudder can make a speed difference of 20 knots if you use the rudder to correct off-axis yaw from one engine). And that is just for LockOn/A-10C. Rudders are essential for helicopter flight (BlackShark). You'll also use rudders to correct for thrust changes in propeller-driven aircraft due to engine torque effects and the spiraling prop-wash hitting your vertical stabilizer (causing an throttle-setting dependent yaw effect). Hopefully Battle of Britain: Storm of War is not too far away and will almost certainly include these effects (IL-2 does).

Good luck on that work. Note that there are existing F/A-18F and F-14D meshes and skins (as well as flight models etc) made available in the VNAO Flaming Ciffs 2 mod. See the 'mods' link at: http://www.virtualnavairops.com/ If using the VNAO FC2 mod you can try the Hornet and Tomcat models out on the 'stallturn.com' server (disclaimer: my experimental server running the VNAO mod). Just thought it may save you some time if you weren't already aware of the VNAO mod (and avoid re-inventing the external models when you could instead spend time on making a great cockpit).

One of the files (somewhere in scripts/database I think) lists what pods must be carried to use what missiles. I tried adding the correct pods to a player-flyable EFA (Extra Flyable Aircraft) mod BAE Harrier to be able to use ALARMS but it didn't work (despite having the correct pods loaded), but I think if you have the correct pods on the correct aircraft that AI may be able to use them. Perhaps you should try altering the F-16s pod loadout and see if that gets the HARMs to go. @Ethereal: It is a shame that Mavericks are used before HARMS since the latter has a vastly better range - thanks for reporting your observation. Edit: With regard to AI you can see some of the sequencing in Scripts/AI/Tasks/ but you can only get so far as these seem to call functions that are compiled in (C++) libraries I think. Edit 2: Scripts/Database/db_weapons.lua lists weapons and whether something is required to use them. For example, the AGM-88C has Required = { req_launcher("{8C3F26A2-FA0F-11d5-9190-00A0249B6F00}", "ECM Pod"), }, Perhaps it is worth loading that F-16 up with pods and seeing if that makes any difference.

AGM-88 HARM targets radar emissions only (although it has 'memory' an inertial guidance if an emitter turns off). That means SAM radars and combined radar+launchers (eg. SA-15 Tor) but not launchers only (eg S-6 or SA-10 launcher). nb. SA-11 Buk has combined radar and launcher, so should be targeted.

Please note that for A-10C Beta you want to do the opposite, let the application do the anti-aliasing. It may be worth setting up different profiles for LockOn/BlackShark and A-10C to configure the graphics settings correctly.

A-4 is the "F-16 of the 60's".

I voted "no". I think the huge number of no votes is not a statement of any lack of confidence in ED, merely a reflection of the current state of the A-10C Beta and an understanding that work remains. If anything, I hope it shows ED that the community knows it will take time to shake the remaining bugs out and get everything up to commercial production quality. In this sense, I consider the Open Beta has been a huge success in (mostly) getting everybody's expectations aligned - and placating the impatient. Despite the huge PITA it must be for ED and the Tester volunteers, I'd say that this process ought to be repeated for the next in the DCS line (plus, it injects some extra income into ED from the enthusiasts and 'early adopters' while they work on finishing the product).

Of course. All the "I want x, but want someone else to do it for me" must drive you guys bananas - and yet the ED testers are always here answering questions. Awesome.

Note that the vast majority of users won't complain because they simply don't know any better. This is not their fault, they've never seen a state-of-the art low-effort manual - except maybe for Apple manuals that also follow the principles I espouse [eg. notice how Apple use illustrations sparingly but appropriately due to the maintenance overhead - this is excellent tech writing and part of their overall design quality]. So I don't think the argument that "user's don't complain" invalidates the fact that the manual could be written better and once re-organized would allow users to learn directly from the manual (and the thread topic is about improving the training - which is why I suggest the way the real pros do it). Yes, I'd love to write a decent procedural manual for this sim. There are several barriers in the way: 1) Ownership. I'm guessing the original author may be required to assign copyright to ED if the work was a substantial part of the product. There are licenses out there that would protect both ED and the original author - but the situation is unclear and it seems ED's position (at least in the past) was that stuff built on their products should result in a substantial revenue percentage to ED (which means they have a conservative view of how an ecosystem can be built). This has discouraged me from spending the effort writing a substantial training manual for LockOn using a proper methodology. 2) Time. I've just spent months working on a stats system which I intend to share with everyone. I've spent so much time working around bugs in the logs produced by FC2/BlackShark (and there are a lot) that I simply don't have any spare time over and above the 20-30 hours a week I devote at the moment making LockOn resources to make a manual as well. I think there will be a lot of strange additional bugs that will crawl out of the woodwork once the stats go live and that doesn't mean I'll be free after release either. Oherwise, I'd do exactly as you say and shut up and sort the manual myself (although I'd certainly be berated on these forums for doing so - suggestions are often met with a large degree of hostility here). 3) Who receives the money should write the manual. My post was a suggestion that a low-effort re-organization of the manual would make all the difference in the world. I attempted to explain why I felt like I was qualified to make this suggestion in the hope it might allow the efforts of the *existing* team to be more efficient and produce a higher-quality output if they learned a proper technical writing methodology (eg Information Mapping, which takes 0.5 to 2 days to learn, so not too onerous). This was never intended to belittle the effort of the team in any way, just say that improvement could be made for little additional effort by the existing person/people that are *paid* by ED to do this job (or already volunteer). I have suggested minor non-contentious improvements to the documentation in the past but they have been rebuffed in a dismissive manner. From that I gained that there was no point in me doing anything greater - it simply wouldn't be understood enough to be appreciated. No problem, but no contribution to the docs either. I can only give you the benefit of my training and experience in this field with suggestions (lead horses to water etc.) - but cannot sort it out personally since I'm tied up contributing to DCS/FC2 elsewhere (hundreds of hours of effort to get real-time stats that are maintenance free and with low enough overhead they can be run on the same machine as the game server). The tech writing methodology I suggested is sound and better than what is being done now. Please take the time to check it out otherwise the current writers missing an opportunity to go from good to great.

PhD vs military flying vs civilian flying Actually for a PhD you must retain a lot of information (I have one in Physics/Astrophysics) as you need to see a big picture and tie things together (like remember much of the detail from 200 terse research papers in your literature search so you don't end up re-inventing the wheel). Before that I was in the RNZAF as a pilot (flew, but did not complete Wings. The RNZAF trains all its pilots to fighter pilot standards and can choose only the best). Flying is not intellectual at all - it is not even in the same ballpark as an Baccelaurate let along a PhD. Military flying is very different to civilian flying as well - you must learn (physical skills) extremely quickly to graduate military flight training whereas civilian flying you will always graduate provided you have the money. My point is they are different things requiring different skills (and one is not necessarily "better" except for a limited purpose). Reorganization required These days I'm a developer but also occasionally do technical writing and training of complex subjects (eg. enterprise software systems and applications such as accounting systems for mega-enterprises). Hence I feel qualified to offer a professional opinion on this debate. As a technical writer (trained in the "Information Mapping" methodology, eg. see http://en.wikipedia.org/wiki/Information_mapping for a brief overview) I actually agree with the original poster. The manual is laid out poorly compared with the Falcon manuals. The differences are subtle so not everyone notices, but some do. It is not a problem with the quality of writing, simply that the organization is naiive and not set to well known principles of learning. I'm suggesting that the manual is adequate but can be improved by a re-organization (clearly too late for A-10C, hopefully done for whatever is the next DCS module {DCS:Hornet, I wish :) }). The DCS manuals give you a whole bunch of background stuff that is of interest but actually mostly useless when you are in the cockpit. Embedded in that are some useful things, so you end up having to read it all and sorting the wheat from the chaff. It is assumed you want to read the entire 600+ pages before you get started. That is simply not the way people learn technical skills. The material needs to broken into chunks far more and organized so that you can easily find all the relevant information on a single topic (without having to read all the proceeding topics either). In fact, this "breaking into chunks" partially arose from studies of pilot overloading in the Vietnam War when great progress was made on the psychology of learning and task management. Reorganize with a more procedural/task-based orientation Note also that even real pilots learn things broken into seperate chunks; basic circuits, basic comms; basic emergencies; basic dead reckoning; then they move to night flying; formation; aerobatics; cross-country navigation; low-level flying; etc then finally progressing to operational flying (tactics, BFM, strike etc as needed). They learn things by the *tasks they must perform* not jumbled as a mass of reference material. The A-10C manual is a step forward for ED manuals since it includes a lot more procedures. These procedures (mostly in the form of checklists) are quite brief though and are more aided at memory joggers (as real aircraft checklists are) rather than learning tools (which would have slightly more information to assist the learning process). For the entertainment market I believe the latter is in order (always know the level of audience to write for!). Procedures are more instructional and easier to create and maintain than videos While video instruction serves the role of a real instructor the effort required to produce it is enormous. As a result the coverage of video is quite poor. Video is good for orientation and introductory material but that's as far as it good. Video also is a pain if you want to go over a point within the instruction as you have to watch the same thing again (a very slow way of learning). Rather than more video it would be much better to have properly written procedures to learn from (the Falcon manual had some of these in its tutorials, and exercises to put it those into practice) - these procedures are: * faster and less effort to create * contain a lot more detail than video (in the form of notes and branching paths) * can be reviewed and scanned quickly when trying to recall a specific point. * can be organized so that related material is in the same place in the manual (eg. a section may be on different ways of using the TGP, another section on the Maverick Seeker, another on different ways of navigating). When properly organized this allows you to quickly locate a task within the manual and learn that task (eg. navagation) *without having to read the entire manual first*. Note: excessive screenshots are also a maintenance hassle. There should be some for orientation and reference purposes but they are not required (nor recommended) for every step of a procedure. Final points So, IMHO the A-10C manual has great information but what it really needs is re-organization along the lines of proven learning techniques such as Information Mapping. A mere re-organization can turn the same content from hard to learn into easy to learn (in stages). Please don't give feldwebel a hard time. He actually made an extremely valid point that unfortunately was not accepted by some who appear slightly defensive in their outlook (hey, we all love these sims ok) or have never seen a technical instruction manual done properly (so cannot imagine how a manual could be improved from the current state). When you see a technical manual done properly you'll see that the A-10C manual could be improved enormously for both us 'hard core' sim-junkies as well as more casual users - it is possible! nb. notice how by the simple use of labels I could break an enormous chunk of text into bunches of related concepts that you could easily navigate between? A similar simple and quick re-organization would similarly improve DCS manuals. The most important thing is that this can be achieved with little effort (economy of effort to write and maintain a document is very important). Finally: real pilots learn this stuff over 2 years and then perfect it over a career. Some of us have a couple of hours a week. To be effective the DCS training material and manuals cannot be exactly as real pilots are trained as the time available is smaller - the DCS material should not necessarily be exactly as terse as real checklists since the audience is different [again: write for your audience].