TwitterFacebook

Why the F-35?

By ckfinite | Published March 23, 2015

The F-35 is one of those projects that people love to hate, and it’s very easy to do so. It’s incredibly expensive (the entire program, out to about 2050, will end up costing nearly $1 trillion), the aircraft itself has had teething issues, and questions have been raised about more or less every aspect of the F-35’s performance. However, I think that the F-35 is a highly suitable successor to the F-16, the F/A-18C/D, and the AV-8B, for a number of different reasons.

Let’s start with cost. The F-35 is planned to cost $85 million when full rate production starts, and costs $106 million right now, in LRIP 8. Furthermore, the Israelis bought 19 at $145 million each (including the entire rest of the support system). These are big numbers, but consider this – the UAE just bought 35 F-16 E/Fs, the latest and most comparable model, for between $161 million and $200 million each, also including support costs. The F-35 costs less than the latest F-16, then. The project estimates operating costs between 10% and 20% higher than those of the F-16, with current (test) O&S costs about 42% higher.

To discuss performance, we need to consider all the various things the F-35 does and consider them separately, comparing its performance to the airplane that it’s replacing in that role.

Fighter/Air superiority

Neither the F-35 nor the aircraft that it is replacing are air superiority fighters, per se. Instead, they are designed to make things on the ground explode first, then fight other aircraft second. However, the F-16 and F/A-18C/D have set quite a high bar for the F-35’s performance in this role, and it at least needs to do as well as its predecessors. In general, the F-35 doesn’t end up that badly in comparison with the F-16, at least kinematically. While performance data is mostly classified, pilots have said that the the F-35 can outturn a F-16 when both are carrying combat loadouts, a advantage made even more profound when the drag of the F-16 is increased by adding the conformal fuel tanks on the F-16 E/F. Additionally, the F-35’s acceleration at the same effective range is similar to that of an F-16, again putting it in approximately the same ballpark of kinematic performance.

Additionally, in comparison to the F-16 and F/A-18C/D, the F-35 has a critical advantage: IRST. The F-35 integrates a all aspect IR system called EO-DAS, combining IRST, MAWS, and navigation cameras into one unified system. This allows the pilot to see through the aircraft, removing the rear-facing blind spot as well as enabling the pilot to look through the floor of the aircraft. When combined with the other major benefits of IRST, most notably long range visual identification, this provides the F-35 with a major advantage against the legacy aircraft that it replaces.

In terms of radars, the F-35 wins yet again. The F-16 is the only predecessor that can even come close to competing, since in it’s E/F incarnation it carries the AN/APG-80 or a derivative of such. However, the F-35’s AN/APG-81 has 65%more elements, providing it with better beamforming ability.

Loadout-wise, the F-35 performs somewhat worse when limited to internal configurations alone. Until a tentative block 4 upgrade (to 6 internal), it can only carry 4 AMRAAMs internally, compared to the F-16E’s 4xAMRAAM + 2xAIM-9X or the F/A-18E/F’s 6xAMRAAM + 2xAIM-9X. This can be rectified by adding external weapons, up to the same 6xAMRAAM+2xAIM-9X as the F/A-18E/F, but the performance takes a hit and LO advantages vanish entirely.

Strike

The F-16 and F/A-18 were superlative strike fighters, and the F-35 continues that tradition. The platform provides better penetration, range, and ESM, all while maintaining similar payloads and self-defence capability. The F-35 can reach a combat radius of 613nm when carrying the maximum internal 2x2000lb+2xAMRAAM internal loadout, while maintaining penetration. Combined with its substantially higher usable payload (18,000lbs vs 17,000lbs (F-16) or 13,700lbs (F/A-18C/D)), the F-35 can hit its targets harder, further away.

The F-35 additionally adds the EOTS sniper pod system, essentially the well regarded Sniper XR pod, except mounted internally. This prevents the F-35 from having to carry a heavy and draggy external target designator pod as the F-16 and F/A-18 do, and enables every strike package member to self-designate LGB strikes.

Furthermore, the VLO capabilities of the aircraft become hugely useful in this regime. The F-35 can approach closer to radar sites without detection, enabling it to maximize range by reducing deviations around EW systems as well as penetrate deeper before employing weapons. This capability is largely retained against even metric-band systems, though detection range with these systems is increased due to larger RCS.

CAS

The main advantage of the F-35 in the CAS role is the integrated sniper pod. Every F-35 will have an optical system on it, not always true of the prior platforms (especially Harrier). This enables any F-35 to be able to provide CAS, no matter the low-altitude environment, while the VLO features enhance survival against medium range threats. Modern sniper pods provide substantial resolution, even from very high altitudes.

This high resolution capability enables identification and accurate targeting, even when friendly infantry is close to the target, and also enables the FAC to acquire better battlefield intelligence when combined with the ROVER datalink system.

Based on these features, the F-35 can provide comparable or better performance in the roles that it was designed for, all at somewhat reduced cost. Because of this, I think that the F-35 is a sensible investment as the US’s next fighter platform.

Posted in Analysis, Article | Comments Off on Why the F-35?

Guidelines and Suggestions on Side Proficiency

By Coiler12 | Published March 20, 2015

I eagerly took advantage of the side proficiency setting options in Command as soon as they became available, using them in many of my scenarios. When 1.06 was released with the option of setting proficiency for individual units, I became even more interested.

Many have undoubtedly asked “what determines the ideal setting for a side”? Now I can give the rough guidelines for how I choose proficiency settings-in the event that I choose them. Before I continue, I should emphasize that there is no harm in leaving both sides at “Regular”. Having done it myself often, the scenarios play extremely well even without the different effects caused by side proficiency, and it should not be something that the scenario author should obsess too much about (in other words, when in doubt, just go back to “Regular” for all sides).

That being said, here are my basic guidelines.

Regular

Regular is the default proficiency, I interpret as a ‘mixed’ force. Not (necessarily) an elite or battle-experienced faction, but one that has seen some fighting, or at least conducted reasonable training, and that knows something. From “Regular”, the faction can be more or less proficient.

Novice and Cadet

“Cadet”-level proficiency factions/units are ones that I interpret as having just a lack of something-maybe it’s training in the wrong way, maybe it’s a lack of resources, an over-politicized crew selection, or something different. “Novice”-level ones either have a combination of those or one of those carried to an extreme degree. They can also be, as their names signify, new to the equipment in question and thus unable to use it to the fullest.

Veteran and Ace

“Veteran”-level proficiency exists in those factions/units that have something more. They have the combat experience that their name implies, they can be highly selective and demanding in their training, or they can have a degree of both. “Ace”-level was one I felt uneasy applying to entire sides-I reserved it for the elite “Aggressor” sides in training missions, with the (player’s) trainees having much less skill.

So that is how it often works in my mind with side-level proficiency. Note that I avoided using specific national examples. This is because such comparisons lead to ugly beliefs, and also because the same nation can change dramatically over time.

Enter 1.06 and its ability to set proficiency for individual units. This allows for even more flexibility. Here’s how I changed my guidelines to account for it.

-Natural variation in proficiency. Some units will be above the median proficiency and some will be below it. A few pilots will stand out, and thus have a much higher proficiency than the side as a whole.

-Selectivity in units, either for better or worse. Either the best aircraft get the best crews-or they’re new/pushing the crews to the limit, and thus get lower proficiency.

-If two or more countries are on the same playable side, the variations that would make one nation’s proficiency different from another can be shown while keeping them both in the player’s control.

-Related to “selectivity”, certain units within a side (one example being special-forces supporting aviation like the 160th SOAR) can be set to a proficiency that matches their maximum training.

-Also related to “selectivity”, when I use two-seat training versions of an aircraft or dedicated trainers in a combat role, I take it as a sign that the instructors of that air force are thus being pushed into a front-line role in them and thus up the proficiency of those aircraft.

This is admittedly much work, so it is acceptable and understandable to either stay with “Regular” or select a uniform proficiency, especially in expansive scenarios. But adding the styling of different proficiencies can make a scenario that much more distinctive.

Posted in Analysis, Article, Command: Modern Air/Naval Operations | Tagged: , . Comments Off on Guidelines and Suggestions on Side Proficiency

The Power of Overlays

By comsubpac | Published March 15, 2015

One of the great things patch 1.07 added to the game was the possibility to load several layers of overlays automatically and an easier way to build a package to distribute them together with your scenarios. Overlays make the game more beautiful and add a great amount of immersion to the game.

Preparations

To make great looking overlays you need four things:

  1. GMap.Net
  2. An image editing program
  3. A text editor
  4. The game

When you are about to make overlays for a scenario, you most likely already have Command installed. Baloogan has modified GMap.Net specially for use with Command. His version can be found here: Baloogan’s GMap. As an image editing program I use GIMP. GIMP is free and can be downloaded here. To edit the .pgw files you can use every text editor but personally I prefer Notepad++.

Making the Overlays

When you want to make Overlays with several layers it is important to know which areas are to be covered by the scenario and where the player will zoom in to see more details and how much details he might want to see.
At the moment I prefer making up to five layers of overlays where necessary, with an increasing level of detail.

Getting started

Start up Command and load the scenario you are interested in, or create a new blank scenario, to get an overview over the Area the overlays are supposed to cover. Now start GMap and scroll to the Area you need.

Overlay GMap overlays

Of course a map doesn’t look good as an overlay but it makes orientation easier. To create your first overlay switch to one of the satellite views (1). I prefer BingSatelliteMap. After that click at “Get Static” and adjust the zoom level. Starting at Level 9 is a good idea when you want to cover a bigger Area without too much detail. Be careful a bigger area increases the risk that the overlay doesn’t fit.

Overlay GMap 2 overlays

Once you are are satisfied click “Generate” This will create two files at your desktop (‘.png and ‘.pgw’). To test if everything went right go to Command and load the overlay.

Overlay CMANO 1 overlays

After this continue to make overlays at different zoom levels. I like to use the levels 9, 12,13,14 and 15. In my example I am interested in Hamburg in general and the Hamburg Airport in particular. You can of course use every combination of zoom levels but be careful: with higher zoom levels the files can become very big very fast. This is not so much a problem as long as you only want to use the overlays yourself but it is problematic when you plan to share your work with others. The size of the files in the example is at this point 66mb.

Overlay CMANO 2 overlays

This already works but looks a little bit too artificial. To change that you can use GIMP. Open the overlays one after another and

  • Use the “free select tool” (1) to cut everything away you don’t want.
  • Click at: “Alpha to selection” (2, right click),
  • Select, “Shrink”, (3, right click)
  • Select “Feather”. (3, right click)

Gimp 1 overlays

This reduced the file size to 56mb and is a good opportunity to rename the files to something more convenient. It makes loading the overlays easier. They have to be named in a certain order since the overlay loaded last will be placed over the overlays loaded before. I use the following pattern: “0_Hamburg1.png, 1_Hamburg2.png,…” The first number represents the zoom level if you have made several files with the same level. It is important that the corresponding .png and .pgw files have the same name.
Now we should take a look at what we have achieved:

CMANO2 overlays

This looks like something we can use for a scenario.

Adjusting the Size

56mb is not a suitable size for distributing the files to others. An easy way to reduce the size of the files without loosing too much details is the “scale image” feature of GIMP. Rescaling the pictures by 50 percent reduces the file size to 10.2mb.
After those changes it is important to edit the .pgw files accordingly. You can open the files with Notepad++ or every other text editor. The first and the fourth line have to be doubled.

The magic of Lua

As mentioned before, one of the features introduced with 1.07 was the possibility to use Lua to load overlays using an event. This and the ability to make a package makes using and distributing overlays much easier.

 Preparing the overlays

First make sure your game does have the “Command Modern Air  Naval Operations\AttachmentRepo” directory. Load an existing scenario or create a new blank one. Go to “Editor->Scenario Attachment” (1). A new window will open. Click at “Create new, Type of: Map Overlay (Single Image)” (2). Load one of the overlays and repeat the step for every file. The game will save the files in the AttachmentRepo folder.

Package1 overlays

You can skip the next step but it makes writing the script easier, especially when you have already other attachments in the AttachmentRepo directory.
Go to “editor->Package scenario for distribution”. A .zip file will be created in the directory you saved the scenario. Unpack the “attachments” folder. This way it is easier to find the GUID used in the Lua script.

Setting up the event

The best way to load the overlays is an event using the “scenario is loaded” trigger. It is important to set the event to “Event is repeatable”.
To Load the overlays the triggered event needs an action. The action is the Lua script. Insert “ScenEdit_UseAttachment(‘AttachmentNameOrID’)” for every overlay you want to load. To find the GUID go back to the “attachments” folder you unpacked earlier. The important part is to load the overlays in the right order. Search for the “0_Hamburg1.png” and copy the name of the folder, for example “ac15fb3a-d2c1-45c9-91f7-e4deb7a4991c”. Repeat that for every overlay. Your script should look similar to this:

ScenEdit_UseAttachment('ac15fb3a-d2c1-45c9-91f7-e4deb7a4991c')
ScenEdit_UseAttachment('30e0c9fe-130b-491c-aa8a-88094197f26d')
ScenEdit_UseAttachment('a81e0a5c-e822-4cc8-856f-879a873ee98d')
ScenEdit_UseAttachment('516e919d-ea61-48f7-bdf1-6d5c3d8583a5')
ScenEdit_UseAttachment('5083bee2-7d99-4e40-a17c-29dd97e75f07')

Testing the package

Delete the .zip you created earlier and repeat the steps to build a package for distribution. Now delete to contend of the AttachmentRepo. Unpack the newly created .zip and load the scenario. The event should fire and the overlays appear automatically.

Using the package

Using the package is similar to the last step above. Just unzip the files into any directory and load the scenario. The attached overlays will be moved into the AttachmentRepo and be loaded every time the scenario is started.

Posted in Article, Command Lua, Command Resources, Command: Modern Air/Naval Operations | Tagged: , , , , . Comments Off on The Power of Overlays

Looking back at the OPFORs

By Coiler12 | Published March 11, 2015

In the early 1990s, the US Army released a set of documents describing the “capabilities-based OPFOR” (Opposing Force), a stand-in enemy force that could be used in training exercises. The documents describe the organization and tactics of both a “Heavy” and “Light” OPFOR nation.

As reference tools, they remain extremely valuable. While obviously dated given their age, listing the basic organization, formation, and tactics of conventional militarily units from top to bottom is extremely helpful for understanding the process of mechanized war. While the OPFORs are obviously based on a Soviet system, Western-based ones are not so completely different that the documents lose all their value. (Often stereotyped as inflexible, Soviet doctrine focused primarily on focusing the flexibility at a different level.)

In the decade of peace between the fall of the USSR and 9/11, there was uncertainty as to what the army would-do. This uncertainty (deliberately, to allow many training situations as possible) shows in the organization of the two OPFORs. The “Heavy OPFOR” is a highly thinly-veiled stand-in for Russia-its units are the most Soviet, and its equipment charts list material found in no other country at the time of writing. The “Light OPFOR” is more reminiscent of (former) Soviet client states given second-line gear, and to potential opponents that remained for the US to fight.

The Light OPFOR’s manual shows the trend towards unconventional war well underway. While its unconventional actions go under the Cold War heading of “People’s War”, the use of asymmetric tactics against a superior adversary that its leadership knows it has no chance against in a straight-up fight are covered. One part of it-of scattered and bypassed soldiers in the regular army turning to unconventional warfare, came to pass in the Iraq War, although due to the circumstances of the conflict rather than by Saddam’s choice.

However, it is not a nation-building manual and focuses purely on the battlefield aspects of unconventional tactics. This is not surprising when one knows that is intended for short-term exercises.

I may be overthinking the OPFORs, putting too much value into understanding something aimed at providing a “heel” (to use the pro-wrestling term for an antagonist) for exercises. But the OPFOR pamphlets are readable and educational nonetheless. Probably the most “useful” are the organizational ones (if one looks at them with the knowledge that even the best-maintained force will never have its exact on-paper strength in the field) and the lower-level “tactical” ones, both heavy and light. But even the less “realistic” ones have much value.

Posted in Analysis, Article, History | Tagged: , . Comments Off on Looking back at the OPFORs

What is in a (Ship) Name?

By Coiler12 | Published March 6, 2015

I like to use fictional ship names for Command. First, using fictional names lessens the need for the sort of direct 100% accuracy, such as putting a ship in the wrong geographical area. Second, I simply like thinking of names.

For navies/ship types with established naming conventions, (people for American destroyers and frigates), finding a name is easy. This applies not just to types but to individual classes. If a certain class of Soviet destroyers was named after animals, I can easily pick out fictional names.

There are two stumbling blocks for ship names. The first is if the units are rare and valuable enough that one has to use them. For France’s carrier, unless you have an alternate history where they built more, to use any name but the Charles De Gaulle is inherently inaccurate. Even though there are considerably more American carriers, each one is distinctive enough that it feels off to name one differently.

The second is units that don’t have names at all, but just numerical designations. When it comes to substituting units, it’s easier to swap “USS Morgan” for “USS Fletcher” than it is to swap “U-100” for “U-99”-both existed, while the Fletcher-class “USS Morgan” did not. Either I would accept some inaccuracies or find what number the sequence stopped at and name the units above them.

Of course, for ships never built at all, one can be extra-creative with the names. I had fun naming a Project 71 carrier (historically just a paper ship) the Marshal Tukhachevsky (after an innovator in combined arms warfare that Stalin purged). The idea was that Stalin ordered the carriers built, and by the time Khrushchev replaced him, they were either complete or too built to practically cancel. So, as a form of trolling/irreverence, Khrushchev would name the carriers after Stalin’s enemies, and one such carrier sailed into battle against American submarines in a scenario.

One can always fall back on the historical names if coming up with fictional ones is too much work, or if they desire greater accuracy. But there is something to naming one’s own fleet.

Posted in Article, Command: Modern Air/Naval Operations | 1 Comment

Modeling Political Influence in Command

By Coiler12 | Published February 20, 2015

Political restrictions and influences have always played a part in war, and several Command scenarios have taken this into account. To what degree political difficulties should be implemented depends greatly on the context on the scenario. The tools a scenario designer can use include: geographic restrictions, point penalties, indirect political effects and the briefing.

Geographic Restrictions

No-navigation zones have been frequently used to simulate off-limits areas. These work, but are imperfect. They have an inherently “gamey” and crude quality to them. Especially in earlier periods of time with vastly inferior navigation, this can lead to unrealistically good awareness on the part of the units involved.

This is not to say that no-nav zones don’t have their uses. I’ve used them without any regrets, and they work for “simple” issues. A “Don’t fly over Iran” instruction, when the targets are not anywhere near the Iranian borders can work for no-nav zones. In this case, the instructions are clear, and since the target is far away from the restricted area, there’s less chance for panic to lead to a mishap.

What can work better than simple no-nav zones is having consequences for entering the restricted area. The official scenario “Operation Lightning Strike” illustrates this well-go anywhere but over Pakistan to hit the nuclear missiles, and you will face the wrath of that country. Lua has made the possible responses more varied and effective.

Point penalties

Point losses for violating the specified orders are common. To what degree they penalize the player should depend on the context. My own scenarios have ranged from a response that amounts to “Eh, try not to hit any civilian fishing boats even though they’re reporting your position to the enemy anyway” with no actual point losses should the boats actually sink for a 1940s sense of ethics, to a “Any loss of either civilians or an E-3 AWACS with a large crew will cause the scenario to be failed”, for a mission conducted by an under-resourced country that cannot afford an American backlash.

There is a middle ground, and exactly how much depends on the nature of the forces involved, and what the political situation is. The comparative restraint or ruthlessness of an army often goes against the stereotype of how it “should” behave.

Combinations

One of my attempts at innovation was modeling an arbitrary restriction-in the first Rollback scenario, non-stealth aircraft were not to cross the 31st parallel except in case of emergency. What I did was painstakingly create “unit enters area” triggers for all carrier aircraft except the A/F-117 stealth fighters themselves, and assigned those to an event that led to a small point loss for the American side.

This illustrated a violation without being an immediate scenario-ender, and allowed for certain types of aircraft to be deployed while others were incentivized to stay behind in a way that a cumbersome no-nav zone could not accomplish.

Combinations like this have many possibilities. A Vietnam War intrusion into Chinese airspace could trigger a massive point loss, a flavor message saying that President Johnson wants to give you a good talking-to, and huge numbers of J-5s scrambling to guard their airspace. Better keep a better eye on landmarks next time, Mr. F-105.

Indirect political effects

Politics is more than just direct restrictions. Politics can influence force skill (altering the proficiency of certain units), deployment (which can range from interservice rivalries shutting one branch out on one end, or an Eagle Claw-level pileup of including everyone whether it really makes sense or not on the other), and command structures (best achieved by multiple sides that do not necessarily have access to each other’s data). As this is “background” politics as opposed to obvious limitations, the scenario creator would (as I have often done) be entirely justified in not mentioning it in the briefing.

Briefing/flavor

Briefings are excellent at simulating a political mood. They can be vague and even wrong on purpose. Similarly, flavor events can enhance the desired tone even if they have no effect on the scenario itself.

In conclusion, there are many tools at a scenario creator’s disposal for simulating the effects of political influence on a battle gamed out in Command.

Posted in Article, Command Resources, Command: Modern Air/Naval Operations | Tagged: , , , , . 3 Comments

Lua in Play – Using Lua to Implement Scenario Functionality

By ckfinite | Published February 18, 2015

Lua provides a vast number of new possibilities for scenario creators, letting you automate tasks. Today we’re going to discuss how you can use Lua in a real scenario, using my upcoming Operation Fei Lian as an example. We’ll discuss how to integrate Lua into your scenario development workflow, and also how to implement solutions to some common problems.

The Setting

The name Operation Fei Lian tells some of the story behind the scene. Fei Lian is the name for the Chinese god of wind – and in the scene, three winds are sweeping North Korea:

  1. A literal wind, making the skies abnormally clear
  2. Yet another internal coup
  3. A Chinese attack in support of that coup

The PRC intends to help topple the Kim dynasty by military force, a task eased by the unusually clear skies over the country. However, there are some complicating factors: the North Korea’s nuclear weapons – a force that could potentially kill millions of Chinese. The PLAAF must destroy the DPRK’s strategic air and missile forces before they can be used to retaliate against the PRC.

This idea, originally by JanMasterson, really intrigued me, as it depicts events that aren’t usually seen in Command. Playing as the PLAAF is unusual, compounded by the complex relationships and timing inherent in a nuclear counterattack. Before 1.06, Command couldn’t simulate a randomized event chain like needs to happen here, but not modelling the missiles leaving their hangars, the nuclear integration time, etc, would leave the scenario rather lacking in detail. Lua was the solution.

Planning

Lua requires some forethought, like any other scenario. You need to figure out what needs to happen in your scene to implement it with Lua. The major component in Fei Lian was the North Korean nuclear retaliation pipeline – integrating a process including missiles, airplanes, trucks, and a palace.

In-game, the process works like this:

  1. T+0: Realization of PRC hostility (attack/entry into NK airspace)
  2. T+20m: Conventional forces launch (KPAF mass scramble), special forces ready (IRBMs to launch locations)
  3. T+30m: Nuclear go: Trucks carrying NK nuclear weapons depart from Kim Jong Un’s palace to the aircraft and (randomized) missile launch site
  4. T+~1h: Nuclear weapons arrive at ballistic missile launch site, and begin integration.
  5. T+1h30m: Nuclear warhead integration complete, missile launch against Beijing
  6. T+1h45m: Nuclear bombs arrive at MiG-23 bases
  7. T+2h: MiG-23 with nuclear gravity bomb ready – air attack on Shenyang

This chain of events would be hard to do in Command in the pre-Lua days – especially the randomized nuclear missile selection process. To implement this sequence of events, you have to keep track of which units are where and when they start out, hard with the traditional mission editor, much easier with Lua.

The implementation of this system has these trouble spots that need Lua solutions:

  • Timing events in general (e.g. event A happens, then B happens 30m later)
  • Departure of nuclear missiles from hangars to launch sites
  • Missile selection for nuclear delivery
  • Nuclear integration (only one missile should be nuclear, not all of them)
  • Transportation (tunnels through mountains)

Implementation

The actual implementation of the solutions to these trouble spots is beyond the scope of this article, but they provide some insight as to what’s possible with Lua right now.

Timing is the big part – Lua allows you, via the Siberian Humvee method, to schedule events in the future. This lets Lua implement some interesting things, including simulating strategic OODA loops, but also how long it takes for a truck to get through a tunnel, for instance.

Another part of Fei Lian implemented with Lua is storing ground vehicles in hangars. In the past, you couldn’t put a truck in a hangar, as a limitation of the engine. However, Lua lets you simulate the truck being inside, by spawning it at the right time and only if the hangar hasn’t been damaged yet.

Lua lets you go even further, though. A problem in Fei Lian was that you, with the traditional event editor, could destroy the same TEL out of 9 to ensure that no nuclear weapon was launched, because the nuclear warhead’s destination has to be fixed. That’s no longer the case – Lua can store what’s arrived where, so that the nuclear delivery trucks can make an intelligent decision about which missile gets a special warhead.

I plan to describe how these features were implemented in a series of tutorials on my website commandlua.github.io, explaining the Lua features involved and how to apply them in Command so that you can add Lua to your toolbox. Lua allows you to extend Command’s scenario building capabilities manyfold, both when editing (as JanMasterson described on Friday) or in the scenes directly. If you want to play Fei Lian, take a look at it here.

Posted in Article, Command Lua, Command: Modern Air/Naval Operations | Comments Off on Lua in Play – Using Lua to Implement Scenario Functionality