Recreate Radar Jammer effect

I was thinking about the same idea until I ran into this.

[RADJAM] ;Some RADAR Jammer truck
....
....
RadarJammer=yes ;the same as the person mention above ^.
JammingRadius= ;Radius of the RADAR Jamming effect in Cells Def=0
....

RADAR jamming was a strategic asset to the first Red Alert thats too good to lose its light of day for YR++ :P
~Gamingroach

Is RadarJammer like Gap Generator or what? never played a C&C game older than YR.

Not quite, when you get that vehicle within a certain distance of an enemy radar, said player's radar map shuts down.

wow Radar Jammer is great.
One of my top wishes after I read above post.

This should be doable relatively simply, the real challenge will be crafting the scanning system in a way that doesn't bog down the system.

I'll try this one. :)

I use his already in Rockpatch
It works with custom Armor types
and Ares have custom Armor and EMP so this works.
well, maybie not ;)

It doesnt work properly with custom armour types
For if the enemy has any more than one building with Radar=yes then they still have radar

In other words the custom armour/EMP work around only works for one target at a time rather than all targets in a radius

P.S. Would be nice to see the RA1 radius logic for other things too, such as mobile Gap Gen and Mobile Stealth Gen, so that the units dont HAVE to be deployed to have those abilities

-SMIFFGIG

Then buy more Radar Jamming vehicles to disable more radars?

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r733
Revision comment:
Creating feature branch for issue #305, 'Recreate Radar Jammer effect'.
SVN: http://svn.renegadeprojects.com/Ares/733

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r772
Commit contains DLL: No
Revision comment:
Merged trunk r740-r771 into issue #305 feature branch.

Related to issue #1171, which still very much deserves its relation to #1172.
SVN: http://svn.renegadeprojects.com/Ares/772

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r773
Commit contains DLL: No
Revision comment:
This should, in theory, implement issue #305.
In practice, it'll probably make the compiler cry and I'll have to fix it up to even compile, and then we'll have to see if the algorithm even makes sense. ^^

But I'm sure our oh-so-active cadre of testers will happily check that, right?
SVN: http://svn.renegadeprojects.com/Ares/773

Alex has compiled you a nice testing build for this in r781 - and nobody has checked whether this thing even runs.

So gogogo testers. Without feedback, I can't continue.

And what are the exact tags for radar jamming?

RadarJamRadius= (int, I presume, defaulting to 0), I guess. At least that's the only radar jam related tag I could find during my quick search through the dll.

Yeah, that's it. Thanks. Measured in cells, and goes on TechnoTypes.

alright, gave rhino a RadarJamRadius=30 and played against russians. Radar went offline as soon as the tanks approached my base, that part works fine, but the radar seems to stay jammed even after the jamming unit(s) have been destroyed.

Ah, yes xD didn't account for that. Will fix, thanks.
Does the radar properly return online if the tanks leave?

And how's the performance of the algorithm? Any noticeable hit?

Didn't notice any performance hit, and the radar returns properly when the jamming unit moves away far enough :)

In other words, the logic itself works fine, I just didn't account for the death case? ^^ I like the sound of that. :D

- Death to the Jammer
- EMP to the Jammer
- Temporal to the Jammer
- Lack of a driver in the Jammer
...any other deactivation cases I have to account for?

dunno if these are covered already... (too tired to test right now XD)
- what if the Jammer deploys into a building?
- What if it's loaded into a transport?
- Does Grinder count as death? (I guess so, just asking to be sure ;)
- what happens when it's sold?

that's all I can think of right now.

Radar jamming works fine indeed, however there seems to be a case when it does not happen.

While a jamming unit disables radar when coming nearby Yuri's Radar Dome (standard radar building), it does not disable radar when coming nearby a Construction Yard from a special mode Foresight in my mod, in which there is no shroud and CY itself provides radar.

CY provides 25 power units, so I thought that was the reason and yup - it was. When CY takes 25 power units instead, jamming works correctly but I was amused by the fact that I was not able to build anything from that CY. All structures' icons from the sidebar were gone.

I take it that jammer simply makes a building with Radar=yes and Power

Interesting case...
The Jammer calls a stock function aptly called GoOffline(), that's about it. There isn't really a way to affect radar itself, since the question of whether the building has radar or not is saved in the type information, not on the individual building, and we can't turn off radar overall, since the player may have a radar building out of range of the Jammer.

I'll see if I can find a way around it, but I can't promise anything.

In the meantime, can somebody check if radar jamming still works if the radar has TogglePower=no?

It does.

Good. D has provided me with a hook inside a key function, which should allow me to fix a variety of the "involuntary Radar Jammer removal" scenarios later.

If Alex will be around for compiling, you should be able to test it tonight.

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r787
Commit contains DLL: No
Revision comment:
Almost completely rewrote issue #305 - Radar Jammers to be more flexible, maintainable and more in line with other controllers in the game.
zzzJammer is now a pretty much self-contained JammerClass under Misc.

Added D's new hook, and I added Radar Jammer under TechnoClass_Update_CheckOperators, so many death-like and disabled scenarios should be covered. EMP might still be an issue, depending on whether it sets Disabled or not.

NOTE TO COMPILER: Since I'm working from ./src only, DEFINE_HOOK(6F6AC9, TechnoClass_Remove, 6) still has to be added to the .inj.

NOTE TO TESTERS: Since this is an almost complete rewrite, you'll have to test this one from ground up. Sorry.
SVN: http://svn.renegadeprojects.com/Ares/787

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r795
Commit contains DLL: No
Revision comment:
Thanks to D's wisdom, this branch might actually compile now.

Related to issue #305.
SVN: http://svn.renegadeprojects.com/Ares/795

Code related to this issue has just been checked in!
Author: AlexB
Location: issue-305-radar-jammers, r799
Commit contains DLL: Yes
Revision comment:
Related to issue #305: New Radar Jammer branch binary.
SVN: http://svn.renegadeprojects.com/Ares/799

Ok, jamming still works, but
1) hard crash when the jamming unit moves back out of JamRadius.
2) "double" crash when the jamming unit is destroyed (two crashdumps).

crashdump from 1) http://www.ppmsite.com/rotd/debug_rj.rar
crashdump from 2) http://www.ppmsite.com/rotd/new-crashdump.rar

Ouch :S Thanks, I'll look into it.

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r800
Commit contains DLL: No
Revision comment:
Yeah, that was my bad. Converted something I shouldn't have converted during the recode.
Sucks when you do it right the first time and then "fix" it to crash. >_<

This should fix the range-leaving crash and at least one of the death crashes. If the other death crash still persists, we'll need the dump for that one.

Speaking of which, thanks a lot to D and Alex for their dump reading skills. :)

Related to issue #305.
SVN: http://svn.renegadeprojects.com/Ares/800

Code related to this issue has just been checked in!
Author: AlexB
Location: issue-305-radar-jammers, r802
Commit contains DLL: Yes
Revision comment:
Related to issue #305: Another new Radar Jammer branch binary.
SVN: http://svn.renegadeprojects.com/Ares/802

If this DLL still crashes on Radar Jammer destructions, could someone test if any and all destructions lead to crashes, or only Radar Jammer destructions, please?

Also, reaperrr, debug.log is complaining about your HTNK configuration. Just sayin'.

Code related to this issue has just been checked in!
Author: AlexB
Location: issue-305-radar-jammers, r805
Commit contains DLL: Yes
Revision comment:
Related to issue #305: New Radar Jammer branch binary.
SVN: http://svn.renegadeprojects.com/Ares/805

Moving out of JamRadius works fine now, no crash and radar restored correctly.

Unfortunately yes, any and all destructions seem to lead to crashes now, even killing an unmodified Conscript...

http://www.ppmsite.com/rotd/r805-dump.rar

>>Also, reaperrr, debug.log is complaining about your HTNK configuration. Just sayin'.

Thanks for pointing that out,I guess I was messing around too much with some settings...

Suckage. I'll see what can be done about that, I think/hope it's an issue with the remove hook. Will need a fearless dump reader to determine the exact cause.

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-305-radar-jammers, r807
Commit contains DLL: Yes
Revision comment:
Related to issue #305 - fixing the evil crash in r805. + additional untested exception handler.
Related to issue 305 .
SVN: http://svn.renegadeprojects.com/Ares/807

Good news:
- Evil crash is gone.
- destroying the jammer correctly restores the radar.
- jamming stops when the Jammer gets EMPed, and resumes when EMP effect wears off.

Not so good news:
The scenarios Speeder described still happen, though.
- If the building is any kind of factory at the same time (and I'm afraid that includes the Allied Airpad), the "factory" part goes offline as well.
- Also, jamming doesn't work if the radar building does not consume power (Power>=0).

@Ren: as discussed on IRC, use these:

DEFINE_HOOK(508EBC, HouseClass_Radar_Update_CheckJammed, 6)
{
 enum {Eligible = 0, Jammed = 0x508F08} Status = Eligible;
 GET(BuildingClass *, Radar, EAX);
 return Status;
}

DEFINE_HOOK(508F91, HouseClass_SpySat_Update_CheckJammed, 6)
{
 enum {Eligible = 0, Jammed = 0x508FF6} Status = Eligible;
 GET(BuildingClass *, SpySat, ECX);
 return Status;
}

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r828
Commit contains DLL: No
Revision comment:
This should implement the alternative way of jamming D suggested; it is not based on power anymore, so positive power related issues and factory shutdowns should disappear.

Please check if radar still properly remains online if the target house has multiple radars, and at least one remains unjammed.

Whoever compiles this should add hooks
508EBC, HouseClass_Radar_Update_CheckJammed, 6
508F91, HouseClass_SpySat_Update_CheckJammed, 6
to the .inj.

Related to issue #305.
SVN: http://svn.renegadeprojects.com/Ares/828

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-305-radar-jammers, r841
Commit contains DLL: Yes
Revision comment:
Related to issue #305 - compiled Ren's changes.
Ren, the Builder automatically manages .inj content, you don't need to report its changes manually.
Related to issue 305 .
SVN: http://svn.renegadeprojects.com/Ares/841

hm, is it possible something went wrong with uploading the DLL? In SVN it still says r807 for the DLL, only the .inj is r841. Didn't notice any changes while testing, so I guess it's still the old DLL.

Code related to this issue has just been checked in!
Author: DCoder
Location: issue-305-radar-jammers, r842
Commit contains DLL: Yes
Revision comment:
Related to issue #305 - fuck you, Eclipse, and your filesystem change monitor. Recompiled the r841 DLL.
Related to issue 305 .
SVN: http://svn.renegadeprojects.com/Ares/842

ok, bad news (again XD).

- jamming does not work, radar stays online
- if a radar within jamming radius of a unit is sold, the game crashes hard (except+log uploaded, if you need the mem dump as well just tell me)

Yeah, the mem dump would be nice.

http://www.ppmsite.com/rotd/crashdump1.rar

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r843
Commit contains DLL: No
Revision comment:
Drastically rewrote the Radar Jammers implementation to be more in line with the new way of jamming.
This simplifies the implementation and also does away with the kept lists of radars, making outdated-pointer-issues impossible.

This also accounts for the yet-unreported issue of one jammer unjamming the building while it's actually still in the radius of other jammers, which the old implementation would have allowed.

It has been reported that D's hook-based jamming doesn't actually work yet, but even if that is the case, do test if you can send the jammers around the map, destroy things, etc. without YR crashing.

Related to issue #305.
SVN: http://svn.renegadeprojects.com/Ares/843

reaperrr: This revision should make the crash you had impossible.
(Which doesn't mean it can't have introduced 10 new ones. >_>)

Code related to this issue has just been checked in!
Author: AlexB
Location: issue-305-radar-jammers, r844
Commit contains DLL: Yes
Revision comment:
Related to issue #305: New Radar Jammer branch binary.
SVN: http://svn.renegadeprojects.com/Ares/844

- crash when selling radar is indeed gone
- no other crashes occured so far

Also, I think I know why jamming doesn't work. It actually does, but only when the building state is refreshed, which seems to happen only when the building is

- built/placed, sold, shot at etc.

when I built a new radar within the jam radius, it actually got jammed. I moved away the jammer and nothing happened, but as soon as I fired on the radar building, the radar got restored. When I moved the jammer back into jamming range, radar didn't get jammed at first, but again, shooting at it solved that problem.

The problem reaperrr describes should go away if you add
TargetBuilding->Owner->RadarBlackout = true;
to JammerClass::Jam() and JammerClass::UnJam(). It doesn't actually blackout the radar, it just triggers the available radar check.

Code related to this issue has just been checked in!
Author: Renegade
Location: issue-305-radar-jammers, r845
Commit contains DLL: No
Revision comment:
Alex suggested this change to fix the unreliable jamming.

Related to issue #305.
SVN: http://svn.renegadeprojects.com/Ares/845

Code related to this issue has just been checked in!
Author: AlexB
Location: issue-305-radar-jammers, r846
Commit contains DLL: Yes
Revision comment:
Related to issue #305: New Radar Jammer branch binary.
SVN: http://svn.renegadeprojects.com/Ares/846

I tested r846 and I added RadarJamRadius=35 to harvesters:
* When playing Skirmish:
  - If I have 1 Radar and an enemy harvester is near of the Radar I loose the radar map until it is far again.
  - If I have 2 Radars and an enemy harvester is near of only 1 of them I not loose the radar map. if the enemy is near of the 2 radars I loose the radar map.
  - If when I'm jammed I kill the enemy unit (or when I have multiple radars I sell the jammed radar) I recover the Radar map.

* Playing in LAN (1 Netbook with WinXP Home and a PC with Win7 Pro, both with wsock32.dll of the "LAN Patch 1.00" in the game folder):
  - "Reconnection error!" as soon as the harvester jam a enemy Radar.
Can someone confirm this in LAN games?

As far as I can tell, in singleplay/skirmish it now works as intended. The RC error FS reported seems to be the only remaining issue.

Yay for progress!

Alright, it's been a week...is there any known bug in the actual functionality of Radar Jammers? As in, any bug that would appear in single player?

Or is the reconnection error the only remaining bug with this?

Requesting the log files (including SYNC*.txt) from the recon error.

I just found the problem and isn't by the radar jammer, the game allow to play LAN games with different Ares versions (in this case r842 vs r846, but I though that I shared the same Ares binaries between computers, my fault).

I continued testing temporal weapons against a vehicle that jammed a radar and works as expected.
Another test is attack with a chrono legionarie the radar jammer -> place a radar in the area effect of the radar jammer and then stop the chrono legionarie attack: it worked as soon as the radar jammer is free.

I see it stable until someone think in more use cases that could not work.

Okay, thanks. We'll look into blocking multiplay between different revisions, but not necessarily right now.

In other words, there is currently no known bug in this logic?

Yes

Neat. ^^ Can I get a few independent comments on this?

No known bugs on my end. Can add this into the main build of Ares, as it works as intended and this issue can be closed.

I'll start by marking this as resolved, then.

Give me another independent confirmation, and I'll go merge it into trunk.

While this is still technically in development, any chance it could be hooked up as a veteran/elite ability as well?

I'd prefer to build a generic framework for more abilities first, but that doesn't mean other coders can't implement this right now.

...you ask that now?

File a request. I'm happy this is finally working, I'm not gonna go and break it again.

So can I get another confirmation?

I jammed the tag into GIs, Flack tracks, and Spy Planes.
They all jammed my radar when they got close and I temporarily lose the spy satellite's ability and regained shroud until the jammers are gone.
I assume that's intentional?

Nevertheless, It works perfectly.

It is indeed.

Thanks for the confirmation, closed.

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r851
Commit contains DLL: No
Revision comment:
Merging Radar Jammers feature branch into trunk. This finishes the implementation of issue #305.
SVN: http://svn.renegadeprojects.com/Ares/851

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r852
Commit contains DLL: No
Revision comment:
Deleting feature branch for issue #305 Radar Jammers.
SVN: http://svn.renegadeprojects.com/Ares/852

Code related to this issue has just been checked in!
Author: Renegade
Location: trunk, r854
Commit contains DLL: No
Revision comment:
Updated manual to include documentation for issue #305.
SVN: http://svn.renegadeprojects.com/Ares/854

Code related to this issue has just been checked in!
Author: DCoder
Location: trunk, r855
Commit contains DLL: Yes
Revision comment:
Related to issue #305 - compiled a trunk binary with the Jammers merged in.
Related to issue 305 .
SVN: http://svn.renegadeprojects.com/Ares/855