Moa

> I haven't bought A10c yet for several reasons, one is the $60 asking price. So, save your pennies, for me it was entirely worth it. When you hear discussion on these forums you might think that the Su-25T's Advanced Flight Model means it is on par with the A-10C. It is not. The A-10C is a quantum leap ahead in virtually all areas of the experience. It looks better, the flying feels better, the immersion is better, there is a huge amount of cool new stuff you can do (buddy lasing, JTAC, fuzing, PGM use, datalinking, TACAN, ILS, navagation computer, weapon release profiles, etc etc etc ....). It took me a while to really appreciate the A-10C (thinking it would be a yawn-fest of turkey shoot bombing from 20 k feet) but now I'm totally hooked - as there is so much more you can do (night operations with NVG blew me away). For me FC2 is now a simple pleasure to fly, just like Rise of Flight. A distorted view for sure, but that is just how good A-10C is, and how much a better virtual pilot you'll become. Plus, if you get up to speed on the systems of the A-10C some of the knowledge will carry over for DCS:Next (where you are doing the work at twice the airspeed). In short, save up (a few less beers for a while [did I really just write that?]) and get yourself A-10C.

Thanks for the expansion Yo-Yo. I didn't say this because I was talking about the English (and I realise there are Russian speakers like yourself who are far more qualified than myself to talk from the Russian perspective). Would you mind giving us the two uses (in Cyrillic please, IMHO it is easier to transliterate from Cyrillic to Latin than start with the Latin and get to correct Cyrillic). Thanks.

@lubey, thanks for your comments. My Russian is rudimentary (as in, equivalent to an autistic chimpanzee) but "raketa" (ракета) is often transliterated to English directly as "rocket", but the true English translation is often "missile". The curves would probably be thought on of in English as "clean" and "[air-to-air] combat load".

If you make edits to the files when DCS is running then they can be reverted as the program closes. This could easily be mistaken as one editor working and another not working. Although Notepad sometimes is useful as it acquires exclusive write access; but it can also be a pain if DCS is also trying to write to the same file [log files for example] (this is why I use the 'baretail' program for viewing files in read-only mode, it does not acquire any write locks that would interfere with logging). So, moral of the story, only do configuration changes when the DCS/FC2 software is not running, otherwise they may be reverted when the (ED) program is closed.

Well, there are things in LockOn and DCS that would be nice to change and there are things that simply don't need to be changed. To me it seems that ED is 'evolving' the system rather than a radical revolutionary re-write as you suggest. Throwing everything out means throwing out all the features and all the bugfixes, all the data and accumulated knowledge, and then spending years (and a lot of money) just to get feature parity. Then you hope that life is easier and you can add stuff at a greater rate and with less defects, but it is always a gamble and systems always get new limitations built-in (especially real-time systems). In fact, when a developer says, "Hey, the system would be so much better if we just started *everything* from scratch, so that's what we'll do" then you have cause to worry. Look at the pains IL-2 Cliffs of Dover is going through as they did a re-write from Java & C++ to C#.Net. Certainly they'll reap rewards (single programming language simplifies things) and end up with snazzy features but in the mean time they are really struggling to match the efficiency of their older code-base. It is always that way and a thorough analysis has to be made before throwing the old code out. 'Old' code is often stable code. New code doesn't have time to have all the kinks worked out. If you don't think DCS is evolving then I strongly suggest you hop in the A-10C and do a night mission with the Night Vision Googles. Crunch, MoGas and I flew one last night and the effects were incredible - from blooming of stars, lights, MFDs and HUD; twinkling (shader convolution effect) of light sources; city lights on the ground; the whole world looking reasonably much as expected through NVG (unlike the postage-stamp sized worlds of Modern Warfare through NVG) - and all running at fantastic frame rates. So, GGTharos' response does not seem to me to be soley intended to insult you, it is just incredulity that you are unaware of the massive changes in A-10C to bring us lovely things like the NVG effects, and the lack of business nous that comes from suggesting the 'tabula rasa' re-boot of an evolved system. Especially a system that has already had a considerable re-architecture. This started with Ka-50, which has a very different internal structure from FC1, and then A-10C has evolved further - much to my chagrin as I struggle to keep up with the changes with my own mods. So, please don't be surprised at the reaction of the team. It's just they have already done a re-write and are evolving from there, even if most people haven't been paying enough attention or don't know enough to notice. Incidentally, I consider my money very well spent on A-10C. Each day I'm seeing more and more little features that make it a wonderful aircraft and entertaining sim. The Warthog is already head and shoulders better than any other sim out there (including Ka-50). If they continue at this rate DCS:Fighter is going to be sublime.

Almost missed this! I'm curious what the issue was Yoda, I'd like to avoid the issue, whatever it was.

Yeah, without us stating it we can't expect them to have ESP :)

Gold indeed. Great work.

Great idea GG, a 'regression test'. However, such a test shouldn't put the devs in a 'straight-jacket' in any way. That is why I was keen to work with the debrief.log as this is an external file that could (and ought to) be independent of the internal changes within the engine. The ED devs would be free to do whatever was needed to get things done internally, and the external (file) interface would stay the same. This stability is important for the longevity of 3rd party software (or on my case, important as it takes me a long while to build stuff based only on using free evenings and weekends). Using the __G (globals?) table is a last resort for me, as it is very likely to change rapidly (as it should, since it is an internal structure). It is nice to know it exists though.

Hadn't seen that table before. Thanks for posting Speed, I'll definitely be taking a look.

I started a dynamicscampaign project. The parts needed are: * mission generator * mission result assessment * campaign database. Of these I pretty much completed the mission result assessment part. This was adapted as the 104th's pilot statistics system - since I don't personally care much for pilot statistics (this is visible at http://stallturn.com/104th/). I started working on mission generation. The ability to read and write the mission format produced an intermediate project called lottu (http://stallturn.com/wiki/en/lottu) for modifying the mission file within a track recording. The mission generation work was not complete. I hadn't started the campaign database but this is the most straightforward part (although still a substantial body of work). You can build a database based on the published Order of Battle for any scenario period. My dynamic campaign system has been on hold for a while as I improve the pilot stats system (there have been a lot of little things, and 'edge cases' with the logs themselves) and also have switched to mucking around with rendering an F-16 cockpit in an external program for a little bit. Unfortunately A-10C patch 1.1.0.8 breaks live statistics. Changes were made to support events (kills, crashes etc) as triggers and this has broken the debrief.log in several ways: * the debrief log is not written until a mission ends. It is a pain to wait 8 hours 'till a mission ends before processing stuff. Worse, if the game crashes before the log is written you get no log :( * the debrief log format has changed. Unfortunately events are not described by a single line anymore so handling events requires keeping more 'state' during parsing. This is not insurmountable, but is a PITA. Log entries should be one to a line and ideally contain everything needed to parse the event (it sucks linking fired, hit, dead events - all events should cover: who (callsigns for players!), what, where, when how). * the default debrief log format misses a lot of information. For example, callsigns are not logged for each event. To get around this custom scripts were written that place this information in the log. Unfortunately insertion of these custom messages does not appear to be working. Worse, the breakage of the debrief log seems to be a result of adding events for mission triggers. However, this breakage could have been completely avoided through the use of a simple extra in-memory log table (at the cost of about 200 kB per mission, that is, a trivial amount) and have each event log to both the debrief log (as was done previously) and to the new event table (used for triggering). So, not only are pilot stats broken since patch 1.1.0.8 it seems that a 3rd-party (eg. me) dynamic campaign is out until this is resolved in some way. Unfortunately LockOn and DCS have a bit of a history of arbitrary changes that break the behaviour that third parties rely on. Which is why many people build stuff which is then not maintained (changes break it and people don't fix it), and makes it hard for people to invest a year of weekends (required for such a large project) when ED can break the interfaces without any notification and for seemingly small changes (where the breakage could easily be avoided). Apologies for the rant, it is just worth saying what happens for anyone contemplating a large 3rd-party project. It is a real shame IMHO. Edit: Just seen EvilBivol-1's post. This is exactly what I was developing, however AFAICS A-10C patch 1.1.0.8 break this goal.

Caution: the track does not always accurately show everything that happened in-game. So take track with a pinch of salt.

Cool. We can't have those Quantas jets falling down if you are off 'playing hooky' with the A-10C :)

Pirates of the Crimean This is mostly intended for use by New Zealand and Australian pilots (to get good pings). On the stallturn server. Mission start: 2011-06-16 07:00 Z (19:00 NZDT) 104th Squadron Teamspeak will be in use again (64.34.167.18:8056, pass "phoenix") Mission Briefing: http://www.mediafire.com/?n7t7xlacnv763kp (12.3 MB PDF) See you kiwis there!

Here's a slightly humorous take on rules for designing PC games for developers - in case anyone missed it: http://techreport.com/discussions.x/21105 Here are the main points, the discussions behind each (in the article) are interesting: I. Thou shalt not shun thine player's mouse II. Thou shalt not accelerate mouse input III. Thou shalt not make a mockery of third-party controllers IV. Thou shalt not mix thine bindings V. Remember thine user-interface conventions and keep them holy VI. Keep thine configurations options exposed VII. Thou shalt allow players to host dedicated servers VIII. Enough with the save points already! IX. Thou shalt not worship false gaming services X. Honor thine modders and mod communities ps. the funny-wording (for non-English first language speakers) is old English to give the article a theme similar to the Biblical 10 Commandments given to Moses.

> Its not the problem to build a cockpit and animate all the analog instruments but its not possible to reanimate the MFD`s and HUD`s ... is it? Not without rendering with an external program (which what I am experimenting with).

Absolutely true. In the Cold War the SA-10 (S-300) was a much bigger threat than the ZSU-23-4 or SA-7, so aircraft flew low (even the mighty B-52 was adapted to fly low) and the pilots trained hard for low-level operations. In Afghanistan (and Iraq, and Libya, once the big SAMS were down) it is much safer to work at altitude, away from machine guns. This does not mean that the A-10C can survive in all wars by flying high (unless the F-117, F-16G, F-22s and F-35 take out all the SAMs first). So your operating altitude depends on what threats you are currently facing. It also means you have to choose a SAM evasion technique appropriate for your current altitude (there is no 'one size fits all').

I do one of four things (some of which are already covered): 1) stay out of the Weapon Engagement Zone (WEZ) if the mission doesnt have a requirement to get close. This can either be from being very high, very low, or not overflying the danger zone (or a combination). Note WEZ increases with altitude to a point, and then decreases near the weapon's ceiling. It means being low can also be a defense from larger missiles (where the WEZ are smallest) at the risk of low-level defences (AAA and MANPADS). The low-level approach to staying out of the WEZ was required in the Cold War (where there were a lot of SA-10 and IADs systems floating about). 2) if I am low enough and head on (no time to turn) I dive down into whatever cover I can find. They are yet to make a missile that can go through a hill. Plus, there is always the chance that the missile will fly a predictive path into the ground before I do. Here you risk running into AAA or a MANPADS. 3) if I am far away I'll put the missile on my beam and climb and descend slowly (keeping speed up). The missile's maneuvering will make it run out of energy before it gets me. 4) if I am close then I will put the missile on my beam. When the missile gets close I pull as hard into the vertical as I can. This relies on the fact that you: * can't outrun a close missile * can't deplete it's energy fast enough * can't pull greater G than a thrust-vectoring missile. * can generate a smaller turn radius than the missile. A fast missile with 30 G turning has a much bigger turn radius than a slower aircraft that can pull 7-9 G. Even though the missile can pull Gs that would crush a human when it is close to launch speed it simply can't pull enough G to match my turn radius. Rather than pulling up you can also pull down if you have enough altitude, and then you'll have enough energy to defeat a second missile heading your way (I prefer pulling up but if depletes your energy a lot). So, what you do depends on your energy, the missile's energy, and the missiles range. Timing and spotting the missile are critical (having a wingman on comms is very handy in this regard - which is why they use them in the real world). Edit: besides using a smaller turn radius to defeat the missile kinematicaly it used to be that beaming would also could cause problems for the seeker head (which has a limited slew rate).

Cool. I'll play around myself with custom F-16 MFDs rather than the LockOn ones as I've been wanting to do that for ages. Don't let me hold you back from releasing the F-16!

Alper22 kindly gave me the mesh for the cockpit (as 3DS and OBJ). It only took a couple of hours to write an OBJ loader and have it project in 3D (I'm using Java with JoGL, so things are pretty easy). There appears to be some reverse vertex normals in the converted OBJ so I've decided to switch to using 3DS directly. 3DS also allows animations of the cockpit controls (eg. landing gear lever). Unfortunately there isn't a decent stand-alone 3DS loader for Java. I'm looking at Java3D (although I personally prefer the bare-metal JoGL for the extra control) but have started writing my own 3DS loader (it's a bastard of a format). At the moment I have no time for the next week or so (trying to adapt the 104th's pilot stats system to the debrief.log changes in A-10C 1.1.0.8 and work commitments) and then I'll be back into it. Once the cockpit model is loaded and shaded correctly the things left to do are: * integrate the view direction with LockOn (easy, thanks to Yoda's work on Leavu2). This means the cockpit will move with TrackIR or whatever you use for pointing in LockOn. * MFD and HUD texture-mapping. Easy. This gives the live MFD and HUD that the 141st guys wanted. * 'Picking' this allows you to click on the MFD buttons in-cockpit. This is reasonably easy. * overlay. There are several approaches for this. I'm gonna try quick n' dirty first and see how that goes. * Optimization. Profiling everything and seeing where performance can be squeezed. Anyway there is progress, a few days of solid work to complete, but finding the time at the moment is the hard part.

Actually, this thread is about 3D. He's not spamming so seems pretty legit to me. Edit: Actually, thanks for all your contributions TOMCATZ. IMHO there was nothing wrong with your post as you were showing how excellent models can be achieved with a set number of polygons (which the thread had started discussing). Please keep up the good work and don't hesitate to show your great models - I for one certainly appreciate them.

Regarding the computation limit: * It takes one woman 9.5 months to have a baby. * You cannot use 9.5 women to have a baby in one month. For some types of problems you can do stuff in parallel (graphics) but other types of problems (eg. carrying a baby) cannot be solved that way (eg. iterative computations that have steps that rely on other steps to be complete first, or network traffic to arrive). Then there is the problem where even if you can parallelize an algorithm/computation you can't reduce the pieces too small and too spread because the overhead of communicating and coordinating between threads, cores or machines dominates the time to compute. IIRC the Australian Air Force built an F-18 flight simulator that used 33 PCs working together (presumably dual-CPU each with multi-cores). For one simulated F-18. IMHO (as a developer) it is amazing what Eagle Dynamics has done with A-10C - and it runs on PCs with a lowly 4 GB RAM and on my venerable Q6600. Sure that F-35 looks amazing. But you're forgetting the multi-million Defence Mapping Agency budget that did the terrain data (both acquiring it and stitching it together so it doesn't have defects). Then there is the team that wrote the software, and the team that built the simulator hardware and electronics interface. Total project cost is millions, as is the cost of a full, movable cockpit with hydraulic throw. Then we get folks on here whinging at the $60 cost of the product, and then there are all those who pirate it. Flight simming is a niche market as it is, and ED do very well with what must be relatively limited budgets compared to 'mainstream' games - and that's before the 'pirates' steal copies of the game. Fortunately ED gets money through military contracts or we would have nothing. Sure it is a nice dream to have Crysis level graphics in a sim, but realistically: * no-one has a PC that can run it, and is not likely to in the future (quantum computers are good for simulating *gasp* quantum systems but are relatively crap at general purpose computing * ED doesn't have the budget or time for the consumer-adaptations of the military versions to create something like Crysis (preferring instead to get aerodynamics and systems right). * Even if ED made such a simulator, no-one could afford to pay what was required to cover the development costs. In short, you're dreaming if you think it is possible to make DCS have a 60 km view radius and render every leaf as in Crysis while having the great systems, battle and weapons modelling of current DCS.

By 'pure-java' rendering do you mean Java2D? This is fully hardware accelerated (DirectX or OpenGL depending on the platform) and does not require JoGL (although can mix rendering with JoGL). One thing Leavu2 could do is remember the aircraft state and only render when the state changes rather than every frame. The aircraft mechanical state changes relatively slowly so this is a good optimization. This would help with the load.

Fantastic Yo-Yo. Thanks for taking the time to answer and put me straight. I had missed that SFM page - it is just what I need.

Fantastic work. Thanks for sharing.