Attila

Congratulations on the release! Seasonal greetings and best wishes for the new year.

Shepski, congrats with the newborn! Good to hear you're alive and well --- that first post was a bit ominous. Swingkid, congrats to you as well, with your job. Does it involve any programming? :-) Take care.

Nice!

Rich, like nscode I thought about suggesting SFX, but refrained from it fearing I would open a can of worms --- executables bring the security threat of possible viruses etc. But very few users run without virus control these days, and I guess this crowd is well used to downloading executables off the net. A nice thing about SFX is it will allow you to create a more "wizard-like" extraction process, with intro text, etc. About time you got your first sticky, by the way! PS. Thanks to all for the tips about utilities that handle RAR, but I simply put "unrar" on the Explorer short-cut menu as the default RAR file action (Tools | Folder Options | File types). That'll do for now.

Great work! I just watched Part 1, and although I am reasonably familiar with the UI, I picked up some nice tips. Thanks! Part 2 is downloading. PS. The RAR format nearly put me off. As far as I know WinRAR is not freeware, and I don't really want another full-blown compression utility. Luckily there is "unrar" --- a tiny freeware command-line utility that unpacks RAR files. Just a tip for the likeminded.

Happy new year!

Nice to see such high praise for Rich's excellent work! I can only concur. Recommended!

Happy holidays!

Thanks, Rich! As always, much appreciated. Downloading now.

Impressive landing and video.

Nice tutorial!

Excellent detail!

A definite milestone in simulator history, and still on my hard drive after all these years.

Great tutorial, as always! Lot's of valuable detail.

Well, this is a long standing and difficult problem. I did post about it, years ago on the Flanker forum, but that archive is no longer available. Anyway, track compatibility is hard and involves the core design of the simulator. As you stated, the simulator itself recreates the action depending on input events stored in the track. Hence the outcome depends on every minute detail of the simulator. A very small change in the simulator can change the outcome totally. The technical solution goes like this: Separate the parts of the simulator that affects virtual world state from all other parts, such as UI, visual effects, camera system, etc. Make sure that this core, let's call it the simulator engine, is deterministic, i.e. that it reproduces the same results given the same start state and input events. It must be indifferent to the particular hardware, operating system, drivers and libraries it runs on. Special care must be taken with "random" events. And so on. Design a versioning-capable API between the simulator engine, the visual system, the UI, etc. By that I mean a module interface that enables different versions of the simulator engine to be plugged in, and still have the whole thing work. Ship all earlier published versions of the simulator engine with the product, and use dynamic loading (DLLs) to select the correct version of the simulator engine needed to replay a track. Do the same for the object database (needed because even a minor change to the theatre may affect outcome — a more detailed body of an aircraft may make a bullet miss, a more detailed mountain top make an aircraft crash, a changed skin may make a comment in the track meaningless, etc.) Do the same for the camera system (not necessary to ensure consistent outcomes, but needed to ensure the cameras replay correctly, so that you see the same thing, voice-over makes sense, etc.). Make track loading version aware. In conclusion, though not technically impossible, track compatibility is complicated. And even if achieved, an old track would still present an outdated version of the simulator — tactics presented may no longer work, flight models and systems/avionics may no longer be the same, and so on. On the other hand, the track would at least play, and would possibly look and play better by virtue of running on an updated graphics engine. If that is worth the effort is the question. Personally, I would like to say 'yes' to that, but looking at the techical challenges I'm doubtful.

Hi Ironhand, nice to see you back in action after that worrying quiet period. I have finally upgraded to Flaming Cliffs so I'm again able to enjoy your tutorials. Looking forward to more to come! This is a great idea. It surely is frustrating and demotivating, to user and creator alike, to see the tutorials rendered obsolete with every upgrade of the simulator. Archiving them as movies would mitigate that. Offloading the movie conversion effort to the community would avoid increasing the surely not insignificant workload that Rich puts into these great tutorials. That said, there are great advantages to be had by having the tutorials in track format also — such as the ability to take control and to study the action using all the diverse camera views provided by the sim. The latter is very helpful in many situations, e.g. to understand how SAMs behave. So I hope tutorials will continue to be made available in this form. Anyway, thanks for the tutorial!

Very impressive!

Much of this thread has focused on the new features a physics processor (PPU) can offer flight simulators, but it is worth emphasizing that the most obvious thing to do is to offload current work from the CPU to the PPU. This should allow more complex simulations with environments containing far more active objects than is feasible today. A flight simulator is at its heart a rigid body dynamics solver that calculates movement, i.e. linear and angular kinematics as well as collision detection. Rigid dynamics is an obvious target for accelleration by a PPU (and an major part of the AGEIA PhysX API and hardware). By just offloading all the rigid body dynamics to the PPU a huge burden is lifted from the CPU, which then can be devoted to doing orchestrating and logic (introducing objects and delegating tasks, execute rules and AI, user interaction and communication). Other functions on the PPU can be exploited as well, such as raycasting for all the radars in the virtual theatre, ensuring that no radar sees through mountains and other objects. It can be used for improving simulation of weather, water and smoke. And so on. The CPU may still have to do the more specialized physics calculations not supported by the PPU API and/or hardware, e.g. aerodynamics. Even so there is benefit from a PPU. The CPU can focus on calculating the forces and torques, based on the complex flight model, leaving the calculation of kinetics to the PPU. On a related note, with PPUs and dual-core/multi-core CPUs, a challenge is to use these extra resources for useful work executed in parallell. Tasks such as physics could be shared on available cores and a PPU if present. For example, orchestrating and logic on one CPU thread, flight models on another, while rigid dynamics is performed on the PPU. All of this requires a transition to multi-threaded software, a huge challenge in itself, but inevitably the next big thing in programming (The Free Lunch is Over).

Successful install I haven't spent much time with Lock On lately (not because of any issues with the product, by the way), but with the patch released last friday, the 200 anniversary of the Battle of Trafalgar, and incidently my birthday, I finally upgraded to Flaming Cliffs and applied the new patch. The online purchase, installation and automatic activation went smoothly without any problems on my system (AMD Athlon XP 1600+, 512MB RAM, Radeon 9550, Windows XP SP2). I haven't had much time with it yet, but it looks great so far. Anyway, nice to see this simulator continuing to evolve, and kudos to the development team, testers and contributors for all their hard work on this awesome product. I'm looking forward to the next developments!

Maybe ED should try this: :icon_wink http://www.eagle.ru/manage_eng.htm

Congrats with the new site! Nice!

Well, let's end this uncertainty. The first formula describes the total work left to do, where n is the estimated size of the problem (lines-of-code, say). To then get at a value for w just estimate a, b, c and d — the linear, polygonal, logarithmic and exponential complexity of the problem, respectively. The second formula states that work is the same as efficiency multiplied by time. Now just estimate p (efficiency) and solve for t (time). With n=10000, a=0.04, b=1.02, c=0.8 and d=1.0009, I get w=8559 (man-hours, say). With an efficiency estimated at p=25*8=200 (man-hours per day), I get t=43 (days), giving an estimated release date of 17 March 2005. :wink:

Well, personally I've used direct and online ordering for years and years. Research the required items and reviews on the net, put in an order and have it delivered on your doorstep --- cheap and painless. For this upgrade I ordered the parts I needed (graphics card, joystick, RAM) from Dabs.com online. Unfortunately not every item was in stock so I'll have to wait a little.

Thanks for the tip, bflagg! Neat site by the way. I liked your screenshot gallery --- very nice! I look forward to finally experience Lock On myself. My computer upgrade should arrive next week, hopefully.

Thanks Alfa, cool to see you're a beta-tester now! Well, I ended up ordering a DabsValue (PowerColor) 9550 128MB. The card is based on a Radeon 9550 (an underclocked 9600 chip), is fanless and hopefully cool enough to run in my current case. While not among the fastest cards today, it supports DX9, so I should at least be able to crank up everything for nice screenshots... :-)