Slitherine

quote:

ORIGINAL: KLAB

-Is DEFCON state going to rigidly direct if you can go intermittent or not?
-Plus will it be applicable to LIDAR?
-will they be LUA'able?

quote:


-The choice of 'DEFCON' as a term is somewhat unfortunate as it has major linkages to global Cold War status. It is workable but could cause confusion.

quote:


Will this be applied to other emitters or just radars? I'm thinking OECM, active sonars etc

quote:


It would be fantastic if this could work as a group control setting: i.e.:
--You have 5 area surveillance radars covering an area
--You group them and apply some form of this setting
--The 5 radars would act randomly but coordinated - so at least one would always be on and when that one randomly turned off, another in the group would pop on etc.

quote:

I suppose it will require us to go back and adjust old scenarios but that will be a great improvement.

quote:


Emission is the time it is actually ACTIVE?
Interval + Interval Random is the OFF time?
What is SLEEP mode in relation to those two?
In the above example the radar is ACTIVE for 30 seconds and off for some random time between 0 and 60 seconds?

quote:


How quickly can some of these large surveillance radars cycle on-and-off? It would be interesting to have a minimum interval depending on platform or era. I imagine a modern solid state radar could cycle much more quickly than a magnetron style emitter.

quote:

That's neat but that's not how that works. There isn't any random variation.

I'd define emission intervals and durations by minutes, not seconds. Otherwise you're going to end up getting some pretty big numbers in there. At sea, EMCON instructions might be stated as something like "10 of the last 15 minutes," or whatever.

It's also different for land based systems versus ships. On land there's a kill chain, where the EW/GCI radars hand tracks off to lower echelon radars which eventually hand them over to missile batteries themselves where the acquisition and tracking radars light up. Depending on what's going on, you might get no warning until the tracking radar lights up. Ground observers are still an important part of this process in many parts of the world as well.

quote:


quote:


-The choice of 'DEFCON' as a term is somewhat unfortunate as it has major linkages to global Cold War status. It is workable but could cause confusion.

-I get that point, as a non-native speaker I tend to use odd vocabulary, especially in highly contextualized situations.
Feel free to suggest a more common term.

quote:

ORIGINAL: Gunner98
I'm not really sure, perhaps one of the pros has an idea. I would suggest EMCON but I think you're already using that.

quote:

ORIGINAL: SeaQueen

Here's something I'd find useful:

In a formation of warships, it'd sometimes be nice to have the option of disguising one's numbers and the types of warships by having a "no unique emissions," option, which would avoid turning on radars which were unique to that ship in the formation. For example in a CSG, it might make sense to turn on the CRUDES radars because there's a bunch of them, but it wouldn't make sense to turn on the CVN's radars because that would just highlight it to the enemy ES. While you can do this kind of thing manually, it gets tedious fast having to check each and every sensor periodically.

quote:

ORIGINAL: SeaQueen

quote:

ORIGINAL: Gunner98
I'm not really sure, perhaps one of the pros has an idea. I would suggest EMCON but I think you're already using that.

EMCON is fine. DEFCON is just plain wrong. DEFCON is was about readiness for nuclear war and didn't have anything to do with emissions.

Btw, something I think is important to think about, before you go all in on this, is that all the capability to do EMCON the right way is already in LUA, so if you're not going to make something better than what is there already, I'd strongly suggest doing nothing at all because it just be creating problem that doesn't exist.

quote:



Agree and would be awesome for some of our LUA guru's to start building libraries of this stuff for people to use.

This being said I'm suggesting something that I'm way to lazy to actually put together but would gladly donate to somebody's patreon for!

quote:

I post stuff to LUA Legion. Feel free to use it.

The problem with LUA is that it's really not suitable for game play. It's better for when you're designing the scenario and you want to get a specific behavior from the computer controlled side. On the human controlled side, we need a better interface

quote:

ORIGINAL: SeaQueen

quote:



Agree and would be awesome for some of our LUA guru's to start building libraries of this stuff for people to use.

This being said I'm suggesting something that I'm way to lazy to actually put together but would gladly donate to somebody's patreon for!

I post stuff to LUA Legion. Feel free to use it.

The problem with LUA is that it's really not suitable for game play. It's better for when you're designing the scenario and you want to get a specific behavior from the computer controlled side. On the human controlled side, we need a better interface.

quote:

ORIGINAL: thewood1

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

quote:

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

quote:


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

quote:

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.