Wanted: A “cool-down“ .lua script for EWRS

[philstyle]

Hi all,

I’m in the process of implementing a modified version of Steggles EWRS scripts into a WW2 context for multiplayer.

In order to reduce some of the accuracy, I’d like to introduce a cool-down timer, which prevents a player or GROUP (I only have one aircraft/ player per group) from calling up the EWRS script until after a delay (time inseconds, to be determined) since that same player’s previous call.

The code would then be inserted into Steggles EWRS.lua file, ideally, as opposed to having it sit alongside as another .lua script.

 

Is there anything like from already from other scripts that I can reference, or do any of the code people out there have a suggestion? I suspect the tricky part will be making sure that the cool-down is specific to each player or GROUP.

Edited March 11, 2020 by philstyle

[Pikey]

It took me maybe an hour in MOOSE (and I'm an idiot) to do a bespoke one from scratch rather than change an existing one, I know that is slightly unhelpful but the point is, that the MOOSE absolutely simplifies heavy scripting and stops the need to rely on folks' existing work and editing, which is often harder than starting from scratch. Happy to share the core of the message below and you can easily read it as a non coder and work out the simplicity, maybe folks can start to see the advantages over more basic frameworks.

 

--FUNCTION CONVERTS INTEGER HEADING TO CARDINAL
function bearingToCardinal(hdg)

if     hdg >= 0   and hdg <= 22  then return "NORTH"
elseif hdg >= 23  and hdg <= 66  then return "NORTH-EAST"
elseif hdg >= 67  and hdg <= 101 then return "EAST"
elseif hdg >= 102 and hdg <= 146 then return "SOUTH-EAST"
elseif hdg >= 147 and hdg <= 201 then return "SOUTH"
elseif hdg >= 202 and hdg <= 246 then return "SOUTH-WEST"
elseif hdg >= 247 and hdg <= 291 then return "WEST"
elseif hdg >= 292 and hdg <= 338 then return "NORTH-WEST"
elseif hdg >= 339 then return "NORTH"
end
end

--FUNCTION BRAA message
function braa(PlayerClientObj,rngGroup )

   GroupNumber = rngGroup:GetSize()
   if GroupNumber == 1 then GroupWords = "SINGLETON"
     elseif GroupNumber == 2 then GroupWords = "TWO-SHIP"
     elseif GroupNumber == 3 then GroupWords = "HEAVY"
   end
   local grpLeadUnit = rngGroup:GetUnit(1)
   local tgtCoord = grpLeadUnit:GetCoordinate()
   local currentCoord = PlayerClientObj:GetCoordinate()
   local hdg = UTILS.Round(rngGroup:GetHeading()/100,1)*100
   local bearing = UTILS.Round(currentCoord:HeadingTo(tgtCoord),0)
   local rangeMetres = tgtCoord:Get2DDistance(currentCoord)
   local rangeNM = UTILS.Round( UTILS.MetersToNM(rangeMetres), 0)
   local aspect = tgtCoord:ToStringAspect(currentCoord)
   local alt = UTILS.Round(UTILS.MetersToFeet(grpLeadUnit:GetAltitude())/1000,0)--*1000
   if rangeNM <= 3 then
     MESSAGE:New("BIGFOOT, FAT 3, MERGED.", 15):ToBlue()
   else
     MESSAGE:New("GROUP ".. GroupWords .. ", BRAA, ".. bearing .. ", "..rangeNM.." miles, ANGELS "..alt..", ".. aspect ..", TRACK " .. bearingToCardinal(hdg).." , SPADES.", 15):ToBlue()
   end 
end

To make that a full GCI (it was only for one target) I'd take a list of all red air groups and build a single message with that function executed on each of them.

 

For WW2, not sure what format they would use for the message, this is obviously modern, but the end result of mine is more accurate than anything else I've seen out there (for modern NATO types) including the inbuilt AWACS call.

I was considering doing a voice for it, that was a lot more effort in fact, as I'd have liked to use the RADIO module in MOOSE to generate line of sight and attentuation of the radio call, but apparently that causes message clipping which affects the spacing of number and message calls and makes it sound bad. I never wanted to recreate EWRS for that mission, just a quick custom call.

Pretty sure it could go further with a lot of effort to do an entire GCI simulation, using New Picture and checking in mechanics, popup and threat calls, converting from Bullseye to Tactical at the 30nm mark, dropping fillers inside 30nm, breaking the timing from minutes above a certain range to 15s in close all automatically or with options... but honestly I've lost my motivation with scripting after ED willfully destroyed a lot of scripting in 2.5.6 and keep shunting visuals over core despite all of what they said at the begining of the year.

TLDR; you have choices, choose the exact messaging yourself rather than bend something else.

[philstyle]

Thanks Pikey,

I'm only after a cool-down timer to prevent repetitive smpamming, rather than a full BRAA/ contact report function (whihc we already have).

 

Although your cardinal conversions are very nice! :thumbup:

[Pikey]

Had a quick peek. OK so, the design makes this difficult, the menu is built every 5 secs on line 179 along with th etarget collection after, and takes the settings of either having regular updates or on demand updates. Would be a lot of effort to unpick that as you would have to decouple the ondemand call from entire menu function, but If you set to only ondemand and raise the timer, they will only get the last update (I think!). That's the fastest workaround I can think of. But I dont know if your objective is to discourage player use or just give delayed updates. Depending on that, depends on whether this is useful or not.

 

 

function ewrs.update()

timer.scheduleFunction(ewrs.update, nil, timer.getTime() + 5) ewrs.buildActivePlayers()

ewrs.buildF10Menu()

 

end

 

 

Otherwise you need to dive in to the dreaded line '666' and pull all that out into a seperate function on a seperate timer.

[philstyle]

Hm.. yes, I see the problem here. Only updating the table every 5 or 10 minutes is going to potentially provide inaccurate (old) information, rather than just locking the controller for a period of time between callups for each player.

 

It seems that providing a constantly updating system that is heavily rounded is going to be a far better/cleaner option.

[Pikey]

I think so based on what I see in the design. I think to meet your requirements the message would be On demand only, and the actual menu item would be force removed each time it was called and force added on the timer. That's why I said you have to decouple the menu part as it's doing the menu higher up. It's a bit messy to consider an easy solution, but short of having a timer running for each player (not a good solution) you would have a central timer and each time the function was executed, remove the menu until the timer is up and then rebuild the menu.