From The Strategy Gamer
Our previous entries were just adding proper unit locations using CMO’s installation library. One goal is to make it big, but also manageable. This next bit will do a lot to automate the boring stuff.
So why do we want to automate the boring stuff? Because if we don’t then we have to either handwave it away or let the player take manual control. By making a system behave realistically we let the player immerse themselves in the narrative and focus on the cool stuff.
Sweden is fairly well covered in radars. Coastal radars. Inland radars. Mobile radars. I’d like the player to keep control of some mobile radars but the bulk will be tied into the Swedish Command network.
This is our intent : Radars in a zone will shut down if a guided weapon is detected in that zone. It will turn back on after 5 minutes PLUS a time penalty for the local C2 network destroyed.
So if the Soviet strike knocks out some of the C2 network it will take longer for the radar to get the command to turn back on.
You as the player might want absolute control but you may keep a radar on, even though it would be destroyed, where in the real world preservation of that asset would be critical.
So how do we detect our incoming strike?
A trigger! In this case a UNIT IS DETECTED trigger. Things get a bit tricky as you can’t select a side but must select a type. Then the detecting side is the Swedish Fixed Radar.
Every time it detects a NEW weapon contact it will fire the trigger. A few problems that you, the astute reader, will see. The big one, any weapon will set off the trigger.
local a = ScenEdit_UnitC()
print(a)
contact {
guid = 'demuu8-0hlu85d71amns',
name = 'VAMPIRE #36',
type = 'Missile',
}
We can query the trigger once it fires in the Lua Script Console (CTL-SHIFT-C). UnitC returns the unit that set off the trigger. In our case all we see is that it’s a missile called VAMPIRE #36. Not much to work with.
>> local a = ScenEdit_UnitC()
print(a)
contact {
guid = 'demuu8-0hlu85d71lvj1',
name = 'MISSILE #40',
type = 'Missile',
}
I spawn in a MIG-29, have it launch a missile at a decoy and now we see it’s named MISSILE. I’m curious as to how the system determines it’s a missile and not a vampire, but I’ll work with what I got.
local DetectedUnit = ScenEdit_UnitC()
local queryname = DetectedUnit.name
if string.match(queryname, "VAMPIRE") then
return true
else
return false
end
Now we create a condition as above to see if the variable contains the string VAMPIRE. That takes care of that problem.
local detectingunit = ScenEdit_UnitY()
print(detectingunit.unit.guid)
local delayScore = ScenEdit_GetScore(detectingunit.unit.side)
local currtime = ScenEdit_CurrentTime()
print(currtime)
local futuretime = currtime + 300 + delayScore
print(futuretime)
local convtime = (os.date('%m-%d-%Y %H:%M:%S %p', futuretime))
print(convtime)
local triggerunit = detectingunit.unit.guid .. convtime
local triggergroup = detectingunit.unit.group.name
print(triggergroup)
ScenEdit_SetTrigger({mode='add',type='Time', name='trigger'.. triggerunit, time = convtime})
local SetEMCON = "ScenEdit_SetEMCON('Group', '"..triggergroup.."', 'Inherit;Radar=Active')"
local RemoveT = "ScenEdit_SetTrigger({mode='remove', type = 'Time', name='trigger"..triggerunit.."' })"
local RemoveA = "ScenEdit_SetAction({mode='remove', type = 'Luascript', name= 'triggerunitAction"..triggerunit.."'})"
local RemoveE = "ScenEdit_SetEvent('TimeTest Event"..triggerunit.."', {mode='remove'})"
local ScriptTextComp = SetEMCON.. "rn" ..RemoveE.. "rn" ..RemoveA.. "rn" ..RemoveT.. "rn"
print(ScriptTextComp)
ScenEdit_SetAction({mode='add', type='LuaScript', name= 'triggerunitAction'..triggerunit, ScriptText = ScriptTextComp})
ScenEdit_SetEvent('TimeTest Event'..triggerunit, {mode='add', isActive=True})
ScenEdit_SetEventTrigger('TimeTest Event'..triggerunit, {mode='add', name='trigger'.. triggerunit})
ScenEdit_SetEventAction('TimeTest Event'..triggerunit, {mode='add', name='triggerunitAction'..triggerunit})
This looks big and mean, but how do you eat a cake? One bite at a time!
In a nutshell we determine the current time, see if there is a delay needed because C2 facilities have been destroyed (another Event) and then we populate some variables to stick into the event trigger. It’s super handy to be able to create an event using Lua.
The last bit of the script is garbage collecting where we turn the radars back on AND delete the now unnecessary event stuff.
Now when a unit fires a VAMPIRE at a radar the entire group shuts off and turns back on later depending on how cohesive the command network is. Now the player has a concrete reason to defend those points instead of just losing some points.
Eventually I’d like this scenario to be played from the Soviet side and this type of behavior gives the Soviet Player a different challenge then just “drive in SEAD, kill stuff, send in more CAS”.
The post Command : Modern Operations – Birth of a Scenario Part 3 appeared first on The Strategy Gamer.
Original URL: http://thestrategygamer.com/2020/03/14/command-modern-operations-birth-of-a-scenario-part-3/