Warzone 2100 Forums

I just committed ECM Jammer support to master. It is not enabled by default, but you can enable it with the attached mod.

Building an ECM jamer turret or tower significantly reduces the max range of enemy vision. This is a nice counter to enemy artillery, since the enemy needs to come up close and personal in order to fire on you. Note that the ECM itself will be visible as a blip, even though other units around it are 'cloaked' by it. The radar detector has also been changed, making 5x longer range, but now no longer able to target any units. It will also show ECM units, allowing you to plan counter-measures before a cloaked attack force is upon you. Note that radar detector uniquely does not need line of sight to work.

Units cloaked by an ECM jammer are given pulsating transparency to visualize the effect and show you its range.

Please give your feedback on this feature.

I liked it =D

Just got round to testing this and I must say I really like it!!

It effectively allows you to make artillery-safe areas on the map, which allows you to get droids/structures closer to enemy before coming under long-range attack. And, like Per says in opening post, it forces the enemy to get up close and personal before attacking your base with artillery.

Also I think the way the radar detector is better too. I know some are annoyed that it no longer acts as a target designator, however for me I think it adds a new psychological element to the game: You know something is out there, in the darkness, but not who or what. All you see is a blip on the minimap and a pulse deep within the fog of war.

@Per: In the JS API the enum<Whatever> methods have a "looking player" param that filters returned list to stuff that player can see. How does the radar jammer / detector affect this? For example, if player has a radar detector which has detected an enemy radar deep in the fog, will the enemy radar be included in the enumerated list?

Hmm. Scripts will return blips as seen game objects right now. I think that is a bug, since they are not supposed to know what these blips actually represent, only their position. Let me think about that, and continue the discussion in a more relevant thread.

Are there any thoughts yet on the designs for ECM jammers?

Maybe a golfball like design that military use?

aubergine wrote:Are there any thoughts yet on the designs for ECM jammers?

Maybe a golfball like design that military use?

actually ECM are smaller more mobile. point defense/offense. ie: like on aircraft, they are a pod on a hard point. i believe the USofA is / was looking at building similar for use on vehicles.

i have not seen anything larger than that , although i have been neglecting my surfing of mil sites lately.

http://en.wikipedia.org/wiki/Electronic ... #Radar_ECM

so as not to be overlooking others...

http://www.ausairpower.net/APA-REB-Systems.html

Ah, you mean something more like this:



And the golf ball design (on further reading) seems to be mostly used for concealing radar detection and listening devices (presumably so the enemy can't see what they are pointed at). So maybe golfball design better for radar detector tower?

exactly... small and able to hide. a white golf ball cant hide. thereby making its EOL predictable. ie: missles centered on it. cant miss it... stands out like a black horse in a field of snow. or if you prefer, a white horse in a tar pit.

Indeed. I think having white ball design for radar detector tower might be quite nice though? Something designed to detect other sensors should itself be really obvious IMHO

@Per: In terms of letting the AI/scripts know about "blips" - what about an enumBlips() method that returns a new object type "BLIP" which has x,y coords and not a lot else? The AI would then know "something is out there" but would be forced to go investigate it with droids if it wants to know more.

I'm sorry for reviving topic. But could anybody plz add this MOD to Addons DB, so it wont be lost in forums here. I think its excellent feature-mod. And would be nice to have it work in 3.1.