- 1 A glimpse into the future of flight analysis
- 2 What's this all about?
- 2.1 I bought (or going to buy) a license of Tacview 1.x, will I have to pay again for Tacview 2.x?
- 2.2 When will it be available?
- 2.3 But, wait a minute! Why call it Tacview 2.0?
- 2.4 Looks great, but does it make sense and can it be done?
- 2.5 So, concretely, what is planned for this new version?
- 2.6 Why rewrite so much while Tacview looks quite nice and powerful? Why not just add the new features?
- 3 The new features
- 3.1 The new terrain is quite nice, so why rewrite the 3D renderer?
- 3.2 Wait a minute! Did I read something about a new Exporter for DCS World?
- 3.3 Why a new ACMI file format?
- 3.4 Do we really need a new telemetry engine too?
- 3.5 Why a new Graphical User Interface when a few tweaks and filters could do the job?
- 3.6 What about the long awaited online debriefing?
- 3.7 When does the real-time flight analysis will be available?
- 4 Managing the risks and the future
A glimpse into the future of flight analysis
You got it: Tacview 2.0 is on its way! The goal of this FAQ is to give you an overview on what is currently going on and what is waiting for you in the next releases of Tacview.
Please, feel free to post any suggestions and remarks – regardless of your aircraft or simulator – on the official threads:
First, let me answer the top questions for many of you:
What's this all about?
I bought (or going to buy) a license of Tacview 1.x, will I have to pay again for Tacview 2.x?
No, you won't have to pay again for Tacview 2.0 if you already bought Tacview 1.x.
Even if the development of Tacview is longer and more expensive than initially planned (probably thousand hours of research and programing), I want to honor all the features promised from the beginning of this project. You will get everything you expected when you bought Tacview without paying more.
When will it be available?
My goal is to release it as soon as possible. I am hoping to have a prototype ready in 2020. That said, it is always hard to plan how much work is required. So this is not a promise.
You can follow the development of Tacview 2.0 on Twitter. Here is the current status of the new modules:
- Terrain – Available in Tacview 1.3
- Online debriefing – Available in Tacview 1.4
- Telemetry Engine – Available in Tacview 1.5
- ACMI file format – Available in Tacview 1.5
- DCS World Exporter – Available in Tacview 1.5.3
- Real-time flight analysis – Available in Tacview 1.6
- Graphical User Interface – Prototyping (planned for Tacview 2.0)
- 3D renderer – Prototyping (planned for Tacview 2.0)
Like you, I don't like to wait for years to get an average product in the end. This is why I'm developing this new version iteratively. You will be able to enjoy the improvements, one by one, each month instead of waiting forever to get nothing... For instance, during the past months I have already started the work by rewriting the terrain engine you can already enjoy since Tacview 1.3.
But, wait a minute! Why call it Tacview 2.0?
I had a lot of goals in mind from the very beginning of this project. During the past ten years, we saw a lot of great innovations in computer devices and capabilities. My goal is now to offer you – in Tacview 2.0 – all what I have initially dreamed about, merged with the most recent breakthroughs. All of this packed in a nice and modern tool which is going to blow away what has been done so far. I want to create the most intuitive, productive and powerful flight data analysis tool ever produced.
Looks great, but does it make sense and can it be done?
Absolutely! This is not a dream: During the past years, I thought a lot about how to revamp Tacview to make it match my initial dream by using all my experience and what can be seen in other products (related or not to aeronautics). From paper prototypes to coding experiments, I have already solved 80% of its development. This new step is as important as the initial release of Tacview!
So, concretely, what is planned for this new version?
Almost everything! I've already rewritten the terrain engine. Now I have to work on a new 3D renderer to make the battlefield cleaner. One of the most important improvements is a new graphical user interface which will completely change (for the best) your experience of flight analysis! A new universal file format will enable us to record and analyze ANYTHING we can imagine. A brand new telemetry system will enable Tacview to digest all these new data, and in real-time so you can analyze flights while they are occurring! (Depending on your edition and your simulator). Another major change is a new exporter for DCS World which will export way more data than today. Please, have a look at the excellent research work made by Vicx to get a taste of what is waiting for you.
Why rewrite so much while Tacview looks quite nice and powerful? Why not just add the new features?
When I started Tacview in 2006, in front of the interest casted by the community, I choose to release an alpha version as quickly as possible so everyone can enjoy – at last – an ACMI for Lock-On. To do this, I decided to build a clean framework (libraries) to support Tacview, but on the other hand, I had to rush Tacview programing to make it available as early as possible.
The downside of it: Despite thinking well everything, eventually, you end with your back to the wall and you will have to rewrite everything from scratch to go further.
The new features
The new terrain is quite nice, so why rewrite the 3D renderer?
First you have to understand that the terrain has nothing to do with the 3D engine used to display it. The new terrain is clean and powerful, it is easy to extend and I'm happy with it. However, there is no real 3D engine in Tacview! What is used to display the 3D view is dirty, inefficient and complex to maintain. By putting a bit of time in the creation of a clean 3D renderer, we'll get a clear battlefield, a new GUI and Tacview will be portable on other devices.
Wait a minute! Did I read something about a new Exporter for DCS World?
I was always both happy and disappointed by the data available from the export.lua scripting environment in DCS World. Happy, because I was able to write a data recorder for DCS. Disappointed, because of the very low amount of data available! To keep it simple: We can only get position, rotation and names of active objects of the battlefield. There is almost nothing about RADARs, static objects (like buildings), waypoints, weather... And this is without taking into account the bad performances (in this case) and the lack of flexibility of the LUA scripting language.
In Tacview 2.0, I'm going to use a new hybrid technique which should open a new world of possibilities. We should get way more data: Like RADAR/TV cones and locks, ECM emissions, buildings, mission plan, and much more! The new exporter will be mostly written in C++ which is also going to fix any potential performance issues and will enable a more efficient file format.
Why a new ACMI file format?
The current file format has been created about ten years ago. It is relatively clean and quite flexible. However, I want something much more powerful. I want something simple to learn, hard to master. Something both very easy to handle for people without heavy technical knowledge and very flexible and powerful at the same time. I also want to get rid of the current proprietary binary format. Both to simplify Tacview and to enable anyone to read and experiment with any file saved from Tacview. The new format is going to be plain text optionally compressed in zip or 7z format. It is going to be very simple to start with and will offer a high degree of modularity at the same time. A draft of the specifications is going to be published in the coming months.
Do we really need a new telemetry engine too?
To manage efficiently all the new data coming from DCS World and other flight simulators, we really need a new telemetry engine! We need something much simpler, cleaner and more efficient memory and CPU wise than the current engine. This is why I'm going to rewrite it from scratch using all the experience gained so far. In the end, we'll get something much easier to extend, which is going to support both data merge and real tile recording!
Why a new Graphical User Interface when a few tweaks and filters could do the job?
For a long time I wanted better ergonomics. I want to get rid of the old ACMI style which is still based on antique flight simulations of the 90'! We need something new and more intuitive, especially when thinking of a tablet version. This is why I think this is the best time for a change! I'm not talking about changing shaded icons for flat ones; I'm talking about a brand new way of tackling flight and battlefield analysis. I want to get rid of the old clumsy lists of events, cluttered 3D view and messy objects lists. Drafts of the new GUI are going to be published in the coming months.
What about the long awaited online debriefing?
The online debriefing is on its way too. It is planned to be fully functional in Tacview 2.0. Meanwhile, you are going to see several little tools appearing in intermediate releases of Tacview 1.3.x. Like bookmarks and shared URLs. These tools are prototypes which are going to be refined over time and eventually put together to build the final online debriefing feature. In the end, this feature will enable several clients to connect to a host which is going to debrief a group of people by controlling the views, selected objects and will be able to outline things in the events and 3D view.
Note that Tacview will not include any Voice over IP tool since there are already great software to do this from Skype to TeamSpeak. Tacview Advanced will be required to be able to host a debriefing.
When does the real-time flight analysis will be available?
To build this new feature, I need first to completely rewrite the way telemetry is managed by Tacview so it can record and analyze in real-time. This feature also requires a new graphical user interface so newly recorded data can be smoothly added to what is already on the screen without stutter or breaking what the user is currently interacting with. The nice side effect of this work is that it will enable – at last – a clean and intelligent merge of any data file into the actual battlefield. For example, while reviewing a flight, you will be able to import any navigational data (like Falcon 4.0 DTC files), and merge data coming any from other sources, all of this transparently and in background while analyzing a flight.
Note that this feature will be limited by the export capabilities of your favorite flight simulator. For instance, Falcon 4.0 does not support real-time data export.
Managing the risks and the future
What are the risks with this new version?
Thanks to preliminary research and prototyping I have eluded any major risk. Everything is developed iteratively and progressively. I'm rewriting each module one-by-one and publishing usable intermediate versions at each step. Like I've done for the terrain engine. Here is a practical example: The new terrain engine is already running in the old Tacview. You can already enjoy some of its new features over the old new terrain (like the infinite horizon to just name one). And what is visible is not even the half of its potential! In the coming versions it will be easy to unlock/develop new features so you could enjoy – for example – real time google map textures streaming for the ground.
The main controversial issue remaining is cheating during network games. This has been discussed a bit, years ago on DCS World forums. Because of the nature of the LUA exporter I was not able to provide a reliable system to prevent users from reviewing flights during network games. This threat may be even more present with the incoming versions of Tacview capable of real-time analysis of flights in progress. With the next hybrid C++ exporter, I'm convinced that I will be able to implement a protection system, let's say based on a password, to prevent flight review without being authorized by the host first.
What about Tacview 1.4?
In the coming months you are going to see intermediate versions of Tacview numbered 1.x. Each version will be used to experiment improvements in the form of prototypes. Your feedback will be used to improve the preliminary design. Like the new terrain, each new feature will be released publicly so you can enjoy them as soon as possible. Eventually, everything will be connected together in the final version 2.0. Like the new terrain, all the new planned features are going to really shine later when they will be all together in the final product.
But where is this damn iPad version?
An iOS/Android version is planned and will be released after the PC and Mac versions have been released. This is because I have to rewrite many things first to make them both efficient and portable. Note that you may have to pay for the advanced iPad/Android versions. Obviously its price will match tablet applications prices which means that the license cost will be lower than the naturally more powerful desktop versions.