Operation Flashpoint Dragon Rising: How to make a mission, 3rd step tutorial

The programming language I dedicated most is classic "C". And OFDR uses a script language called "Lua" and it's quite new to me. So, keep it in your mind that I may use improper terminology or interpretation in this article.
Incidentally, the information described in the help file of the mission editor is all I can find as programming textbook for OFDR. Some mission files are also included in the game package as appendix of the help file.

[source code]
-- lines starting with "--" are comment lines.
-- initial settings
function onMissionStart()
OFP:setObjectiveState("objective", "IN_PROGRESS");
end

-- objective management
function onDeath_jeep(victim, killer)
OFP:setObjectiveState("objective", "COMPLETED");
OFP:addTimer("End", 10000);
end

-- mission management
function onTimerEnd()
OFP:missionCompleted();
end

-- player death management
function onDeath_player1(victim, killer)
OFP:missionFailedKIA();
end

The codes are made from functions. The functions that have the name start with "on" are special functions called "event handlers". The game program uses "event-driven" style and when an event occurs, an event handler is called automatically by the OS. The sample codes use the following event handlers.

• onMissionStart() is called at the start of the mission.
• onDeath(victim, killer) is called at the death of an entity.
• onDeath_XXX(victim, killer) is called at the death of an entity named "XXX".
• onTimerXXX() is called when a timer expired.

Each event handler includes the following functions in it.

• onMissionStart()
  Set the state of the objective as "in progress". Actually, the program works without this line. But it's safe to implement this.
• onDeath_jeep()
  Set the state of the objective as "completed". (Of course, it should be so since it's a promise.) And set a timer with a life time of a designated time. Actually, the program works without the timer... in an ugly manner. Without the timer, the screen turns into the ending shot at the instant the jeep tries to explode dramatically.
• onTimerEnd()
  Set the state of the mission as "completed". Without this, the mission continues and the player has to roam about eternally even though the player has completed the mission. (The promise should be kept here again.)
• onDeath_player1()
  Set the mission as "failed, killed in action". Without this, the dead player has to lie there eternally.

By implementing these operations, the minimum requirements for a game are fulfilled. I mean player death management, objective management, and mission management.

The following video shows why these 3 managements are needed.

[notes]
For those who are not familiar with event-driven style, event handlers seem quite incomprehensible; "Why arguments of a function return values? They are containers we set values, right?" The answer is that you should count the OS as one of us. The OS set values into the arguments and call the function, and we have hooked the functions, and we are peeking at the values. Come to think of the case we call a child function through a parent function, it's not so strange. The difference is who called it - the OS. The misunderstanding comes from that the help file doesn't use a word "event handler" and doesn't explain "event-driven style" as well. Or, at least, it would be written somewhere in very small letters.
(In the context of this article, replace "OS" with "game program".)