Well, the mission.scar and .nis files are already pretty good examples of how to do this sort of thing, better than anything I could throw together without a real notion of how the dialog is supposed to flow.
Basically, if you look at an .nis file there are just some unconnected "EVENTS" functions. Intel events (which just play some voice acting files and their text strings) are quite simple, and they are generally commented in the mission.nis files so you can see what is being said. To find out the conditions that trigger an Intel event, you need to search for where the function is called in the mission.scar and see the logic of why that happened.
Probably there are two main types of ways to call events (for our purposes). Rule_AddOneShot() and Rule_AddInterval(). We'll call the opening dialogs a specified time after the game start. Then you call other dialogs when a periodic check reveals that the conditions for those dialogs have been met. Once a Rule added by Rule_AddInterval() plays it's dialog, you can use Rule_Remove() so that the Rule stops being called and the dialog doesn't repeat. You can also have the finished Rule call another Rule using Rule_AddInterval, for if a given bit of dialog should only happen after another. Or multiple Rules can be checking whether the game conditions justify the dialog they have to play.
A simple .scar to control a small amount of dialog might look something like this:
Code:
function OnInit() --starting point of the scar, kicks off our other functions
Rule_AddOneShot(Rule_Opening_Taunts,10)
end
Scar_AddInit(OnInit) --tells the game that this is the starting point
function Rule_Opening_Taunts() --this is run 10 seconds into the game, it establishes whether or not we have a human player against a computer, one being tau and the other being marines
local humanplayer = nil
local Cpu_player = nil
local pcount = World_GetPlayerCount()
if pcount == 2 then for i = 1, pcount do --go through and assign values to
local player = World_GetPlayerAt(i-1)
if Cpu_IsCpuPlayer(player) then Cpu_player = player else humanplayer = player end
end end
if humanplayer and Cpu_player then -- if there were two players, a human and a CPU, both these will have PlayerID values and no longer be nil, so we can
if (Player_GetRaceName(humanplayer) == "space_marine_race" and Player_GetRaceName(Cpu_player) == "tau_race") --check if one is Marines and
or (Player_GetRaceName(humanplayer) == "tau_race" and Player_GetRaceName(Cpu_player) == "space_marine_race") then --the other is Tau
t_playerID[1] = humanplayer; t_playerID[2] = Cpu_player --put our local values into a table so they can be accessed later
Util_StartIntel(EVENTS.IE_Tau_V_Marines) --play an intel event from the .nis (you'll need to write this, it's like the "EVENTS.IE_Eldar_Bastion" example)
Rule_AddInterval(Rule_Exciting_Conclusion, 10) --call the rule that checks for imminent victory and calls the final dialog
end end
end
function Rule_Exciting_Conclusion()
for i = 1, table.getn(t_playerID) do
if Player_GetBuildingsCount(t_playerID[i]) < 2 and Stats_PlayerStructuresLost(Player_GetID(t_playerID[i])) > 10 then --player "i" is probably gonna lose, so
if Player_GetRaceName(t_playerID[i]) == "space_marine_race" then Util_StartIntel(EVENTS.IE_The_Tau_Win) else Util_StartIntel(EVENTS.IE_The_Marines_Win) end
end end
end
Okay, this is just an illustration of the concept, made super simple and not even tested because I just wrote it as an example, there are no nis intel events written for this either. But if you go through and look at the various functions used, you should be able to understand basically how this script works (or is intended to work). The basic idea is to only run the dialog at the beginning (and call the closing rule at an interval) if we have two players, one of whom is a human and the other of whom is a computer, one playing space marines and the other playing tau. If this is the case, we get an opening intel event and begin checking for a fairly hopeless situation on the part of either player, and then call one of two intel events (named appropriately) depending on the race of the player that is about to lose. As mentioned, we could have arranged these in various other contingencies. There could be a longer chain of events that would have to be fulfilled in order (Hah, I've got a barracks and a bunch of guys that are gonna kill you!, now I've got vehicles!, now I'm crushing you with tier 4 ubers!) or we could set them up with their rules running at the same time (we can invoke multiple rules running at intervals), and any combination.
I imagine that your dialog tree will get pretty complex once you factor in all the different races and how they might interact in an otherwise unscripted battle. But hopefully you can get the basic idea of how to control it with this.