We previously advised that we were expecting to make a new public version of IVAC2 available around the end of July… but the more observant of you will be aware that we’re now almost at the end of August. So what gives?
We did actually send a build to the DP teams for testing on 31st July, that we anticipated going to public release a week-or-so later. Unfortunately a combination of technical and personal factors got in the way, and by the middle of August we were already close to having additional features ready, that we decided to wait and release them all together in one go. The latest build went to DP teams for testing yesterday, and currently doesn’t have any reported problems… so it looks like the public release will be available in the next week-or-so.
Here is a quick peek at some of what we have around the corner…
One of the pieces of feedback that we’ve had is that whilst IVAC2 runs nice and smooth on relatively recent/fast PCs, on older PCs it is slower at redrawing the screen compared with IvAc1. Part of that is due to the significant increased flexibility in map-drawing which is available in IVAC2, and so was to be expected. However… we have gone back and re-looked at the internal “nitty-gritty” of the way the maps are rendered to the screen, and made some very significant changes which resulted in 3x – 5x faster screen redraw on the various PCs that we’ve tested it on. That in turn has allowed us to redraw the full window whilst panning the map; previous versions would initially move whatever was on-screen before the pan, and then re-draw the rest later.
The performance improvements also opened up the possibility of adding more complex mathematics in to the map engine. The new version will make better use of map “projections” so that long straight lines will appear to be curved (previously this only worked if the data-preparation teams used a series of short lines). As aresult of the curvature of the earth being properly drawn, we can now more accurately display radial elements (used to represent runway centre-lines, with mile sub-markings); QDM measurements will now also take account of the curvature of the earth and will display a “rhumb line” between the start and end of the QDM; this means that controllers can provide a constant heading for the pilot to fly which will get them to the end of the QDM, unlike great-circles which require constant small changes of heading over larger distances.
On the subject of QDM, some of you may be aware of “magnetic variation” which is the difference between the direction of the “true” north pole, and the earth’s magnetic pole. It’s a complicated issue, as magnetic variation changes constantly as you move around the earth; previous versions of IVAC2 only modelled a fixed magnetic variation for each FIR, whereas the new version calculates it individually at every possible point. Notice how the QDMs in the screenshot above all follow the grid lines, but each has a different heading due to magnetic variation changing significantly near the north pole (in this case, over Greenland). The practical implication is that QDM takes the constantly-changing magnetic variation in to account. Some users may find it initially confusing that north no longer always points “upwards”, being subject to both the curvature of the earth and the variable magnetic variation; we have added-in the option for FIRs to specify that each ‘Preset’ is created automatically rotated so that north (either True North, or Magnetic North) points straight upwards in the middle of the window.
Transponder Code Allocation
The other big feature we added-in this time is ASSR: Assigned Secondary Surveillance Radar codes. Whilst airborne, aircraft set a “squawk” 4-digit code to enable them to be correlated with radar tracks. In reality, specific airports/routes have particular blocks of codes reserved for their use, so that there is less likelihood of two aircraft using the same code. The new version of IVAC2 allows FIR teams to specify the particular blocks of codes, and give them names for the controller to choose from, and then assign a currently unused code from the block. The system goes further, in so far as allowing FIR teams to specify the purpose of each block of codes, and in many cases it will automatically link them to a flightplan at the time of issuing a flightplan clearance using the DCL feature.
The current version of ASSR uses “local” assignment of codes, thatis IVAC2 offers a code which is unused based on what it can “see” from the radar of the airspace being controlled. This is only a halfway point towards the way real systems work, using a central database which keeps track of which codes have been assigned together with the route that the aircraft will fly, so that the system can predict several hours ahead and take it in to account when assigning codes. Unfortunately we cannot yet implement that for use on IVAO, as their servers do not have that capability… which is why we opted to offer the local assignment option until such time as a server solution can be found.
Notice also in the screenshot above, the controller may selected an “Alternate” SID rather than the choice automatically provided by IVAC2 based on the flightplan.
One of the more frequently raised “issues” that we receive about IVAC2 relates to the different way it handles text communication. We made a very conscious decision NOT to replicate the tabbed interface in the IvAc1 COM box, as it could easily and quickly get in a mess with large numbers of tabs open. Instead, we have a single window that allows the status of each message to be toggled “read” or “unread” so that the controller can quickly see at-a-glance any messages that are still waiting to be dealt-with. The downside of that, is the ability to send one message to multiple other users at the same time, which is particularly used by instructors/examiners during training and examination sessions.
We have added-in additional text commands that will automatically “forward” every text message to/from a specified user to another user. For example, at the start of an examination session, the IVAC2 user can configure to automatically forward communications from their neighbouring controllers to go to the examiner; the examiner receives an automatic notification that this is happening (or has been terminated).
We have achieved our first connections to our test network using an early version of our new pilot client software, running with both FSX and P3D simulators. Initial results are very promising, achieving completely smooth position updating of multi-player traffic, and with minimal frame-rate reduction even with large numbers of multi-player aircraft. It’s still at a very early stage of development, and needs various changes to server infrastructure to make it possible, but as a proof of concept it was very successful.
Our primary development over the next few months will be on the behind-the-scenes infrastructure components to enable both the pilot client features and additional radar client features to be added. We are working on a way to maintain backwards compatibility with FSD and still allow new components, such as allowing IVAC2 and TowerView to work together. More news in a future blog!