Matrix Games Forums

I think the entire idea revolves around being able to make missions more dynamic. Turn missions from static mission-specific entities into flexible templates that allows the following:

EMCOM
Speed/altitude/depth
Formation
weapon loadouts
simple lua actions
unit makeup
ROE/WRA
Maybe even damage levels and losses

And probably a few more I can't think of right now. They can be assigned to a group of units by hot-keys, waypoints, events, etc.

Special Actions work, but I think you need something almost like macros.

You could do it that way, but it's a little clunky.

Really like this idea

Hello,

Will ALL of the radars on one side blink on and off together, or is it radar-by-radar?

It is for each individual unit/group


We did some work on it, with better control on which type(s) of detected contact will "wake" the unit, added a custom preset, group Emcon preset, and inheritance from group toggle.



As for Lua binding, these are the currently available functions, feel free to post your requests if there are specifics functions you would like to see.

ClearUnitEmconConfigs(UnitID)
-- Reinitialise the unit or group with default values for all config presets
Exemple :
ClearUnitEmconConfigs("TestUnit")

ClearAllSideUnitsEmconConfigs(SideNameOrID)
--Does the same as above but for all active units (including groups) of a side
Exemple :
ClearAllSideUnitsEmconConfigs("Portugal")

DuplicateEmconConfigToUnit(PresetAlertID, SourceAUNameOrID, TargetAUNameOrID)
-- Copy and paste a config preset from a source unit or group to a target unit or group
Exemple :
DuplicateEmconConfigToUnit("Yellow", "TestUnit2", "TestUnit")

DuplicateEmconConfigtoSide(PresetAlertID, SourceAUNameOrID, TargetSideNameOrID)
--Copy and paste a config preset from a unit to all units of a side
Exemple :
DuplicateEmconConfigtoSide("Yellow", "TestUnit2", "Portugal")

SetUnitIntermittentEmissionConfig(AUNameOrID, PresetAlertID, ConfigurationID, Value)
--Set one of the intermittent emission config for a selected unit or group and alert preset
Exemple :
SetUnitIntermittentEmissionConfig("TestUnit", "Yellow", "SleepModeDelay", 20)

SwitchUnitIntermittentEmission(AUNameOrID, PresetAlertID, Switch)
-- A shortcut to call SetUnitIntermittentEmissionConfig(AUNameOrID, PresetAlertID, "UseEmissionInterval", Switch, ScenarioContext)
Exemple :
SwitchUnitIntermittentEmission("TestUnit","Red",1)

SetSideEmconAlertness(SideNameOrID, AlertID)
--Set the side's Emcon alert level (Green, Blue, Yellow,Orange, Red)
Exemple :
SetSideEmconAlertness("Portugal","Yellow")

I recommend that 'realistic EMCON' be an optional scenario feature like "realistic submarine communications", etc.

This is not going to be everyone's cup of tea, and it might break old scenarios.

OTOH, when it is appropriate to have, we'll be glad to have it.

I don't think it needs to be an optional switch. Just have the default be intermittent not being on. I would assume that alert level in older scenarios would be the highest level. From that point on people can do what they want.

No worries, this won't break any scenario. The default setting is either continuous or not existing at all -> ignored.

For the function SetUnitIntermittentEmissionConfig, would it be better if it followed the pattern already established in the Command Lua API for multiple arguments?

e.g. instead of
SetUnitIntermittentEmissionConfig("TestUnit", "Yellow", "SleepModeDelay", 20)

it would be
SetUnitIntermittentEmissionConfig("TestUnit", "Yellow", { SleepModeDelay=20, SomeOtherConfigID=2 } )

That way you can store configuration info as a table, and quickly swap out different setups. Unless I'm missing something about the way it's currently designed?

EDIT: It would also be good to have a GetUnitIntermittentEmissionConfig returned as a table, if possible.

ORIGINAL: musurca

For the function SetUnitIntermittentEmissionConfig, would it be better if it followed the pattern already established in the Command Lua API for multiple arguments?

e.g. instead of
SetUnitIntermittentEmissionConfig("TestUnit", "Yellow", "SleepModeDelay", 20)

it would be
SetUnitIntermittentEmissionConfig("TestUnit", "Yellow", { SleepModeDelay=20, SomeOtherConfigID=2 } )

That way you can store configuration info as a table, and quickly swap out different setups. Unless I'm missing something about the way it's currently designed?

EDIT: It would also be good to have a GetUnitIntermittentEmissionConfig returned as a table, if possible.

I definately concur on the absolute need for a getter (something EMCON still lacks today), and on the parameter suggestion. Beyond just the latter being in line with typical pattern, taking the table of options to change at once avoids needing multiple calls when changing various entries.

Seems a good addition and appreciate you guys taking some feedback on it during the dev cycle. I'm assuming if I want to control a specific sensor(s) on specific units (not all sensors of type that this feature covers which is def the most common use case for 98% of people) to flip on and off I'll still be able to do that via lua as I can now so long as I don't enable this new feature?

What does the message "Affects the side alertness!" mean? Just a clarification, please

I was expecting something like "It gets affected by the side alertness" (so if I change something within "green", everybody in "green" gets affected)... not the other way around...

But maybe it's something that I'm not understanding (english not my native language!)

Thanks!

thank you for the feedbacks, Lua suggestions are implemented.

Mikerohan, it means the side's EMCON alert level is changed globally, For now, this is placed within the EMCON panel for convenience during development.

I get it now. Thanks!

I noticed on the first post the screen shot shows the Bar Lock radar. Will this feature be applicable to SAM radars as well? For example, the SA-10b uses the Clam Shell as a Target Acquisition Radar (TAR) and the Flap Lid B for TTR/TER (Target Tracking Radar/Target Engagement Radar). On the sensor control panel, I can select one, both or none operating. Will the feature allow, for instance, the Clam Shell to be intermittent and the Flap Lid to automatically track and engage the target? Or more to the point, will this feature be compatible with platforms with different purpose radars?

Also, you mention a toggle "Wake when detecting threat". If there are one or several radars, and it/all happen to be off, how will it/any of them detect a threat? In most western military forces, data links are everywhere. However I'm sure there are other less advanced armed forces with a plethora of data links, so one radar that detected a threat wouldn't be able to (not at least easily/instantaneously)communicate to another radar site possibly scores of miles away.

I think it's a great idea and I hope I don't sound like I'm "splitting hairs".

Would this be available for Sonar too?

It could be very useful to make a ping or two every fifteen minutes or half an hour, just to check for those quiet lurking threats, without continuously broadcasting your presence to the entire ocean.

(Says the guy who just had his frigate sunk because he was too lazy to turn off the pinger! [:D])

You know you want to say it.. Just one ping

https://www.youtube.com/watch?v=jr0JaXfKj68

Mike

[:D]

One thing to consider is making alert level similar to ready times. If you stay on a high alert level for too long, you are forced to drop back a level for a set time. It might end up making things overly complicated, but I think there should be some incentive to not just throw everything at the highest level and leave it.

Maybe something like you can only be at red alert for six hours in a 24 hour period. Or maybe tie it to proficiency. Maybe the alert exhaustion forces a temporary drop in proficiency.

Or maybe tie it to proficiency. Maybe the alert exhaustion forces a temporary drop in proficiency.

I do like this thought. Affects OODA Loop, maneuverability, weapons' accuracy, all the things that degrade with fatigue.

ORIGINAL: thewood1
Or maybe tie it to proficiency. Maybe the alert exhaustion forces a temporary drop in proficiency.

Please don't do that. The OODA loop mechanic is so brilliantly meaningful and simple.

I agree its simple, but how do you model staying at high alert levels for so long? It has to have some effect eventually.