Triggers vs Lua - A comparison.

[Grimes]

This is something I've been wanting to post for a little while, but I've been putting it off for one reason or another. But I've wanted to show off the difference of the same basic mission and how it is built with triggers and how it is built with lua scripting. The mission in question is "The Skies Over Mt Cougar" which has shipped with FC3. The version included is the triggered version, but I've attached it (if you dont have FC), the lua version, and the lua file I use to script the mission. I tried to keep it short, I swear!

 

A quick summary:

Essentially it is a "King of the Hill" scenario with each team receiving more points the more players there are in a given area. Both teams have roughly equal aircraft at their disposal and the bullseye of the scenario is what FC pilots have long called "Mt Cougar". As each team receives points they are randomly given a new asset. These assets range from sam sites, ewr, awacs, and tankers. Each team gets points for destroying the enemies assets. Its a weird balance as the reward for getting assets is also a penalty as you have to protect these assets so the enemy team doesn't get the points. First team to reach a certain amount of points then they are the victor.

 

Now whats different item by item. I can post specific details, but the key differences are:

Scoring

Triggered

-Uses 3 mission goals per player to keep a running tally of "who is where" based on 3 zones.

-Adding a new aircraft to the mission is a PITA

-More points are rewarded with being in enemy zone

-Player count difference is checked based on who is in the center large zone.

-Dozens of triggers analyze the score and define what, if any, asset to give randomly.

-Checks performed at a random rate between

 

Lua

-2 zones are used instead of 3. The zones are smaller and more centered over friendly bases.

-Players receive max points of 1 for being inside the zone and in the air. If they are outside the zone their points are determined by a linear falloff of distance from the edge of the zone

-Adding new players is NOT a PITA because this mission uses MiST (an early version)to get a list of client groups.

-Reward scores are based on a number of factors

-Scores are checked instantly at a much higher rate.

 

Spawning Tasks

Triggers

-Each task is given a required random point value to activate

-Used triggers similar to ones used from On Station to split tasks into categories and to spawn and complete them

-Two triggers per task

Lua

-Each task has same required points value to complete task

-Tasks are defined by a naming convention.

-Since groups cannot be activated with scripting I had to write a 100 lines of code to parse the triggers list within the mission to see if a group was activated by a flag being set to true. I then created a "task" object that is periodically checked to see if the task has been completed or not.

-Each task has its own rules for completion and generally revolve around "Unit.inAir() or Unit.hasAttribute() checks.

-Each task also has to have 1 trigger added to the trigger list to activate the group

 

In the end its still easier to add new groups to a task. :)

 

Messaging

Triggers

-Again used triggers developed from On Station to do messaging. I didn't go overboard with the trigger messages this time.

-Each time a task is completed it will trigger a common message type for the task to appear

-Messages will not overlap due to all messages relying on a single flag being "false" and setting each flag true for a limited amount of time.

Lua

-Created a message system to send messages to each coalition. If new messages are added they are appended to a currently displayed message. This is an early version of a message function MiST will be getting shortly. :music_whistling:

-Using the scoring function from above the mission will also output how many friendly fighters, strike aircraft, and helicopters are in the mission and how many of them are flying.

-Updated status of active assets is also displayed

-Uses "v1" of a response rules script to create messages players will receive when a task is started for finished. The task creation script also figures out a generic name to call the units in the task. An example of a response rule is the following:

['on_activate'] = {
	['vehicle'] = {
	'An OBJECTNAME is going online! Be sure to protect it', 
},
}

The script will replace "OBJECTNAME" with the name of the object.

 

Anyways files are attached below. I thought it might be mildly interesting for those out there who are wondering about the difference between lua scripting and triggers. The overall difference in this example is that lua has a massive advantage in that its easier to add new content to a mission and that the script is much more flexible. However I did have to go through a lot oh hoops to create the entire script from scratch while learning how to script.

Skies Over Mt Cougar_Compared.rar

[Speed]

While Lua is better in this case, I think this comparison is slightly more favorable towards triggers than normal. Normally, a mix of triggers AND Lua will handle complex logic either vastly better or infinitely better than triggers alone can, and do so in a way that is easier to understand and trouble shoot.

 

I say infinitely better, because there's so many things that triggers simply can't do that Lua CAN do. For example, how do use triggers to detect if a unit's altitude above ground exceeds a certain value? You can't. However, a fairly simple script will do this:

do
local unitName = 'Hawg11'
local alt = 1000  -- meters

local unit = Unit.getByName(unitName)
if unit then
	local pos = unit:getPosition().p
	local height =  land.getHeight({x = pos.x, y = pos.z})
	if pos.y - height > alt then
		return true
	end
end
end

 

More examples include line of sight detection, radar simulation, detecting when a specific unit fires a specific weapon, tracking weapon flight and determining where they hit, dynamically ordering groups of air or ground units, detecting when a specific type of unit is in a zone, getting a unit's fuel quantity, getting a unit's life, outputting dynamic messages with like coordinates in them, running logic at faster than 1 time per second, being able to use complex logical statements, getting precise timing, etc etc, etc. None of which is possible at all through triggers.

 

Then there's all the things that are possible to do with both triggers and Lua, and easy to do with Lua, but extremely tedious to do with triggers- things like scoring systems, randomized objectives/missions/groups, detecting multiple units in multiple moving zones.

 

The detection of multiple units in multiple moving zones is what first forced me into using Lua scripting two and a half years ago. I had 18 enemy artillery units (three groups) advancing against 100 friendly units. The 100 friendly units would be under Battle Commander control (back when Battle Commander was going to be a part of DCS: A-10C). The enemy artillery units needed to advance slowly, to stay within range of the friendly units and be able to lay down fire.

 

Well, how many triggers does that require? The only moving zone trigger is Unit in Moving zone. Each of the 18 artillery units needed 100 triggers to detect each friendly unit! That is 1800 triggers total! That is not completely impractical to do, just very time consuming.

 

Then I realized how many fire at points in zones I would have to make to handle the artillery engagement logic- that added like another 1000 triggers to the mission!

 

In the end, I was able to learn Lua, reverse-engineer the scripting engine available at that time (once Swift showed me how to do a _G dump, and I explored some of the Lua files included with the game), and create the same thing through Lua in less time that it would have taken to complete all those triggers! Not only that, the end result worked vastly better than the triggers version would have.

 

Now-a-days, we can just use Mist and accomplish the same action as those 1800 triggers would have done in a single line of Lua. That speaks volumes as to the simplicity of using Lua scripting over triggers for some things.

 

In the end, I feel that triggers are good for simple logic, and for creating a graphical framework from which your Lua logic can run. Most of the time, the best way to do your mission logic will probably be a mix of triggers and Lua, with everything complex being done through Lua.

Edited March 14, 2013 by Speed

[Grimes]

I should probably add that the mission was built before the "expression" trigger condition was introduced, so I had to work around that.

[Sierra99]

I should probably add that the mission was built before the "expression" trigger condition was introduced, so I had to work around that.

 

Good Morning Grimes,

 

I'm just getting comfortable with the ME...And I can kinda make it work (OK I understand how its sposed to work and have lots of time to find my mistakes.)

 

Here's my question. Is it one or the other? Do you open a lua file and go to town until the mission is complete? Or do you accomplish what you can with the ME then enhance things using MIST where the ME is lacking?

 

Are they best used independently or does one compliment the other?

 

Sierra

[Speed]

Personally, I do neither.

 

I figure out what features the mission will require, and form a broad outline of the mission design in my head. Then, the features that are easiest to do with triggers, I do with triggers. The features that are easier to do with Lua or can only be done with Lua, do I with Lua.

 

It is becoming increasingly possible to replace more and more of a mission's triggers with Lua, but we haven't reached that stage where a 100% Lua, complex mission is possible. But the idea that Lua is being developed to replace mission trigger logic is inaccurate. The point of the Lua scripting engine is to provide a much more powerful scripting tool than triggers can ever hope to be. How you use it is up to you.

Edited March 15, 2013 by Speed