MW Mod 6.0 development is now complete! Thread - WIC: Modern Warfare Mod for World in Conflict

World in Conflict: MW Mod 6.0 is coming!

I am pleased to announce that MW Mod 6.0 for World in Conflict has finally reached golden master and is now ready for public release. The mod will be released on August 1, 2020, which is 10th year anniversary for WiC MW Mod since the release of the first Open Beta in 2010.

Version 6.0 is the most exhaustive development in MW Mod history, perhaps rebooting the good old days of the mod during 2012-2014 times. Aside from significant game improvements (such as improvements to AI using an event-based system, integrated countermeasures for Main Battle Tanks and significant improvements to SACLOS anti-tank guided missiles), the crown jewel of MW Mod 6.0 is the introduction of Arleigh-Burke class guided missile destroyer and naval functions into WiC. Functioning naval assets have long been on WiC modders' wishlist since 2008 and that dream has now been finally realized, on MW Mod's 10 year birthday.

Project management from hell: 6.0 development challenges

MW Mod 6.0 development has not been without significant challenges and controversies of its own, taking over a year and two months to develop. Generally, we try to keep release development timeframe to be under 3-6 months, but 6.0 development had suffered significant schedule overruns, milestone slips and other drama. The development workflow was mostly done under 3 person team: one person writing most of the code, another doing intensive debugging, third doing testing.

---

Flexible Interceptor (FLINT) 7

The first development delay came from introduction of FLINT version 7.0.1, which is the most significant upgrade to FLINT since 4.0 in year 2013 (for those of you who don't know: FLINT is a physics integrator that runs all guided homing missiles and projectiles in WiC MW Mod). Improvements brought on by FLINT 7 allowed us to make vertically launching (VLS) missiles possible without running into gimbal locks, which is a requirement for developing naval destroyer (which uses VLS). However, the biggest change brought on by FLINT 7 is the new Advanced Flight Modeling (AFM), which now simulates four forces acting upon the rocket and computes dynamic pressure (Q) using the U.S. Standard Atmosphere model.

In fact, the changes brought on by FLINT 7 on aerodynamic simulation were so significant that not all missiles in game could be upgraded to use FLINT 7 during the development deadline. The amount of time required to perform extended testing for every missile proved to be very tiresome. Most of the major missiles are upgraded to use FLINT 7 code; remaining missiles will be gradually upgraded to FLINT 7 over extended time after 6.0 release. Missiles which have been upgraded to use FLINT 7 as of 6.0 are listed in the Change Log.

That being said, missiles that do use FLINT 7 truly look beautiful, with rockets dynamically fighting through air density and their own weight at different altitudes, and cruise missiles trying to maximize lift by pitching up (induced drag w/ increased angle of attack). WiC is starting to look like a modern combat simulator!

---

All we wanted was a frigging boat..

Work on DDG-81/Burke class destroyer commenced in November 2019. Unfortunately, development of Burke class destroyer in game was riddled with endless challenges and problems that it took longer to work on ship systems than the time it took to release MW Mod 2.0 in 2012!

The biggest challenge surrounding Burke destroyer came from its complex weapon systems, most notably the Aegis Combat System. Code maintainability is the biggest concern in every WiC MW Mod development project: Integrated combat systems are so complex to model with so many permutations to test, that it is important to maximize code reusability whenever possible. This concern was raised, because we already have the Patriot air & missile defense in game, which has recently changed to become IBCS (Integrated Battle Command System) to encompass more than just Patriot in game. Developing a standalone Aegis system would mean that it would become a concurrency nightmare, where any time a new feature or patch is made into the game, we'd have to completely re-test and individually develop new changes to both IBCS _and_ Aegis, making it a nightmare to maintain. Ain't gonna happen.

So the decision was made early on, that IBCS (which runs ground-based SAMs in game, including Patriot) will execute and operate the Aegis combat system and encompassing naval unit software. This meant that IBCS is now in control of both ground-based AA assets and naval assets in game simultaneously, and this is when problems and dramas began to occur.

To simultaneously execute both Aegis and IBCS systems and control them at the same time, a mechanism to provide Inter-process communication (IPC) was required. A few different methods were reviewed, but TL;DR; and long story short, owing to MW Mod's tendency to over-engineer things for apparently no reason at all, decision was made to write a POSIX style execution environment using Python. POSIX compliant signals (including SIGBUS, SIGKILL, SIGTERM, etc), process scheduler, and a virtual machine interpreter were written as Python classes to provide basic control and maintain states of processes. Much of existing Patriot functions run under a wrapper to contain all of the existing legacy code; naval DDG functions are executed under the following new processes: nifcd, aegis-lseqd and awsd.

---

Launch Sequencer and rocket man..

'aegis-lseqd' process controls the Mark 41 Vertical Launching System (VLS) for the Burke-class destroyer in game. The purpose of a launch sequencer is simple: receive fire mission order, validate the fire mission against the requested missile type (to ensure that it meets the dynamic launch zone for that missile), transfer the initial coordinates onto the missile agent, then ignite the missile.

Then of course, we had to complicate things more rather than just implementing a simple launch script. We were adamant that Mark41 cell doors had to be modeled and missile venting/plume animations and so forth had to be all modeled into the game. The first draft of the aegis-lseqd process had functions to sequence and control every single VLS cell. Once firing order is validated and initial coordinates are sent to the missile agent, the workflow is then passed onto mk41_firing_circuit() function, which triggers vent plume animation, then 0.6 seconds later, commands the missile agent to leave the launch cell. After all of this was done, game kept crashing: there aren't enough states for an agent in WiC to individually animate every VLS cell (lol, fail). We then ended up downsizing the scope so that only one single cell per each VLS bank (forward and aft) is animated, but the animation still follows the firing circuit process.

Then there is the issue of firing sequencer: Burke destroyer has 32 cell VLS bank in forward section and 64 cell bank in the aft section. The most smallest Mark41 VLS is an 8-cell module. 32-cell bank is made by grouping four 8-cell modules together, and 64-cell bank contains eight 8-cell modules. Once a missile leaves a single 8-cell VLS module, that module needs to rest for a brief moment (say around 3-4 seconds) before it could fire another missile. Otherwise, vent ducts in the VLS will start to overheat from the frequent excess heat. To model this in game, a time slot is assigned for each 8-cell module in both forward and aft banks -- each 8-cell module takes rotary turn at firing missile (like relay race), thus allowing at least 4 seconds of resting time for a single individual 8-cell module between launches. Then you have two VLS banks (forward and aft), with each bank managing firing of its 8-cell modules -- so in the combined aggregate, the ship can fire off a missile pretty much every 0.5 second or so, giving it an impressive rate of fire.

---

Interrupts..?

Launch orders and fire missions for Aegis are controlled by the IBCS system as described above. IBCS command and control (C2) units in game decide when/what to engage. When an engagement event is generated in IBCS, this message is then relayed over to Naval Integrated Fire Control - Counter-Air/Cooperative Engagement Capability (NIFC-CA/CEC) process. This process is called nifcd (Naval Integrated Fire Control Daemon).

When nifcd is engaged, it checks with IBCS to validate the engagement information. Part of this process is to de-conflict fires with ground-based SAMs. If a Patriot battery is engaging a target track, nifcd will ignore that track. Conversely, if Aegis system is engaging a track, nifcd will communicate back to IBCS that a bird is in the air, so that Patriot can ignore it.

Mid-course updates of outbound interceptors are provided under a Cooperative Engagement Capability (CEC) model. This means that when SM-6 is fired, IBCS ground radars can provide remote updates to the SM-6 -- even if Aegis ship gets sunk and SPY-1 radar goes away, SM-6 will be able to receive updates from IBCS radars and continue on its track.

All of these exchanges of messages are done by generating interrupts. IBCS C2 (rdpd) generates interrupt to wake up nifcd and nifcd also in turn generates interrupt to signal back to IBCS and pass messages to aegis-lseqd when engagement needs to occur, and so forth. To accommodate this, the IBCS virtual machine provides a basic interrupt handler for this purpose. You can actually view the process states as they're being interrupted, by pressing 'KEY INPUT' and then typing in 'A102' under the Interpreter> console. Processes are in either select, RUN or kqread states, depending on active system call at a given frame.

Unfortunately, interrupt routines have proven to be difficult to debug, leading to an extended development period. Bugs causing missing/lost interrupts are particularly difficult to track down, as they cause affected processes to get stuck blocked in their present states. Troubleshooting process states and lost interrupts have been where most of the debugging efforts were spent during development.

---

Walking the targets..

For SM-2MR and ESSM missiles fired by the ship, a new Python class called SARH Scheduler is used. SM-2MR and ESSM use semi-active radar homing (SARH), so they require an illumination beam by one of the ship's SPG-62 illumination radars. However, much like the AGM-114R Hellfire missile and JTAC infantry in game, these missiles have inertial navigation system (INS) in them, allowing them to be fired in the general direction/vicinity of the target zone (called "basket"). The location of the basket is frequently updated by SPY-1 radar via mid-course updates. So, the missile will fly using inertial navigation and mid-course updates toward the basket; once arriving at the basket, target will be illuminated by SPG-62, and the missile seeker will commence terminal homing against the reflected radio beam. Proportional navigation is used during SARH terminal homing.

The use of inertial navigation means that the shipborne SPG-62 does not have to get stuck dwelling on a single target until intercept. It allows many missiles to be launched in series, and a single SPG-62 can "walk" each missile onto a different target by walking the illumination beam from target to target as they arrive. This is similar to using JTAC infantry to "walk" the laser across multiple targets after many laser-guided Hellfires were rippled. With JTAC and Hellfire, you (the player) is manually walking the illumination; however, with Aegis, the computer automatically walks the illumination beam like a pro, down to precise second.

This automation of target walking and scheduling of missile launches (to ensure that they arrive with sufficient spacing) is done by the awsd (Aegis Weapon System daemon) process. A time slot of 2 seconds is used between each missile launch; however, because there are three SPG-62 illumination on the ship, you can salvo a missile pretty much every ~0.67 second. The timeslot is dynamically adjusted based on azimuth/heading coverage of each SPG-62 (so that illumination beam can be quickly walked onto next target for the follow on missile).

Each SPG-62 radar is animated in game as well -- you can see the SPG-62 dish-looking antennas rotate and face their targets as they prepare to illuminate. You can also view the status of each SPG-62 illuminator by pressing 'KEY INPUT' and then typing in 'A800' under the Interpreter> console.

---

One ship, many missions.. and pain

The integration of SM-6, SM-2MR, ESSM, Tomahawk TLAM, Mark45 deck gun and Phalanx CIWS have proven to be very exhaustive and challenging work. Significant part of the problem came from undisciplined management of software development cycles to mod these elements into the game. Looking back, creating what is effectively a virtual machine runtime environment and an interrupt handler are great examples of bloated software development and perhaps excessive over-engineering, regardless of their merits.

Nevertheless, the goals of completing beautifully crafted naval assets and meeting code maintainability ended up being met, so I think we can call this mission a success, but at a huge cost of time and labor.. We're just glad that this is all over now. We look forward to playing the game with the community in August, in celebration of MW Mod's 10 year birthday!

Edited by: blahdy