Omni-directional CUAS jammer

[b-mayr-1984]

When merged adds an omni-directional CUAS jammer.

It is based on the previously named TFAR jammer (which I renammed to voice communication jammer). When placing a jammer as Zeus or in 3den the capabilities of the jammer can be defined (defaults to being the same as the old TFAR jammer).

Camera effect

When approaching the effective radius of an active DroneJammer the controling player's camera will be incrisingly distorted (see screenshots).

When the drone is within the effective radius the player get's disconnected (see screenshot).

Effect on autonomous drones

Non-player controlled autonomous drones get their own server side handling via fnc_jammerServerLoop.sqf, which is quite in line with how jamming works with the Spectrum Device.

Spectral behaviour

Drone jammers have a very distinct spectral behaviour in the Spectrum Device. This shall allow players to locate those jammers (and maybe take them out). In the code this is implemented as a new beacon type called "sweep".

Misc

• I added some minor fixes to existing code
• The radius marker for Zeus I made yellow in case the jammer is turned on (black otherwise; just as it were).
• dev_mini.Enoch has been expanded to test the new features

Notes to maintainer

I was very careful not to affact the existing TFAR jammer functionality. But I did not test it in real multiplayer scenario with multiple human players yet. Same goes for the drone jammer which I only tested on my machine with me as a single client.

• Let me know if I shall join any of your test sessions.
• I will let you know when I did such tests.

(But since this is such a large PR I think it has progressed enough to share what has been done and maybe discuss the changes and how they fit into crowsEW.)

[Crowdedlight]

Looks great! I should be able to go through the PR this weekend! Especially love the detail of the sweeping jammer effect and the visual player effect on camera.

If the player tries to reconnect to the drone after being kicked out, will it still attempt to connect but then kick them the player out again?

And are you including the "fail-safe" modes for drone-signals you suggested in this PR? Or what is the drone behaviour when it gets too close to the jammer? Will the AI and player drones be disabled and stay where they are, until jammer is moved out of distance, destroyed, or drone runs out of fuel?

Can player-controlled drones also be jammed by the spectrum device and give them the effect of visual degradation as long as the jammer is active, or is that behaviour only supported in the new omni-directional jammer?

---

btw, as you might have noticed I added a new wiki for this mod based on mdbook. I have moved over the old wiki stuff and added a bit more. Please include some documentation on how the new jammer works, or is used. Essentially the description and images you have in this PR would do nicely ;-)

You can see the current version of the new wiki here: https://crowdedlight.github.io/Crows-Electronic-Warfare/

You can add new pages in folders or new folders if necessary. Then add them as pages to the book by editing the SUMMERY.md file.

If you want to test it locally, you just need to install "mdbooks" with cargo install mdbook and then in the root of the repo just go mdbook serve and you can see your current state in localhost browser. (Requires you got Rust/Cargo installed)

[b-mayr-1984]

player reconnecting to jammed drone

If the player tries to reconnect to the drone after being kicked out, will it still attempt to connect but then kick them the player out again?

Exactly. One can always re-connect to any jammed drone but is then disconnected immediately. (Happens in fn_jammerPlayerLocal.sqf which runs every 0.5s)

fail-safe behaviour

And are you including the "fail-safe" modes for drone-signals you suggested in this PR?

I assume you are talking about our discussion in #52. Is that correct?

Or what is the drone behaviour when it gets too close to the jammer? Will the AI and player drones be disabled and stay where they are, until jammer is moved out of distance, destroyed, or drone runs out of fuel?

This PR does not change what I implemented earlier bd608cad490a97f13465fcf2fb7686ac5310b57c. Drones will get a disabled AI and eventually land if being jammed for long enough. Once landed they just stay there. If the jammer moves out of range it can even be re-claimed via the UAV terminal and flown away.

jamming via spectrum device

Can player-controlled drones also be jammed by the spectrum device and give them the effect of visual degradation as long as the jammer is active, or is that behaviour only supported in the new omni-directional jammer?

I thought about this for a while. But jamming the RC uplink and the video downlink are 2 separate jamming tasks. The omni-directional jammer is meant as the big gun that does multi-band (or multi-application) jamming. I did not extend the current functionality of the spectrum device for the following reasons. In order to degrade the video downlink the spectrum device would need to be pointed to the drone pilot, not the drone (if a somewhat realistic implementation is the goal). But so far the drone pilots location is not knowable for the spectrum device operator. It could be added that drone pilots are also beacons, so that their location or at least heading could be deduced, but for now I left this out.

But I think what I am currently missing is a forced disconnect from the drone of any controling player when the spectrum device is jamming the drone. Because right now the AI manipulation should be totally ignored by player controlled drones, which makes no sense. Thanks for the question that uncovered this gap. 🙂

Wiki

btw, as you might have noticed I added a new wiki for this mod based on mdbook. I have moved over the old wiki stuff and added a bit more. Please include some documentation on how the new jammer works, or is used. Essentially the description and images you have in this PR would do nicely ;-)

You can see the current version of the new wiki here: https://crowdedlight.github.io/Crows-Electronic-Warfare/

You can add new pages in folders or new folders if necessary. Then add them as pages to the book by editing the SUMMERY.md file.

If you want to test it locally, you just need to install "mdbooks" with cargo install mdbook and then in the root of the repo just go mdbook serve and you can see your current state in localhost browser. (Requires you got Rust/Cargo installed)

Sure, I can give it a look. 🙂

[b-mayr-1984]

But I think what I am currently missing is a forced disconnect from the drone of any controling player when the spectrum device is jamming the drone. Because right now the AI manipulation should be totally ignored by player controlled drones, which makes no sense.

This has been implemented in ef8b62cae2286d39e602d4eb165bf689d4c8bd94.

[Crowdedlight]

Reminder to future self:

• ToggleJamming - JamLoop: I should probably rewrite this loop to be PFH to get out of scheduled space with current spawn. Would make it easier to check if any jam-loops are running. 😅
• might make sense to move all the jamming out of main pbo and into a jamming pbo.

[Crowdedlight]

Exactly. One can always re-connect to any jammed drone but is then disconnected immediately. (Happens in fn_jammerPlayerLocal.sqf which runs every 0.5s)

Makes sense. 👍

This PR does not change what I implemented earlier bd608ca. Drones will get a disabled AI and eventually land if being jammed for long enough. Once landed they just stay there. If the jammer moves out of range it can even be re-claimed via the UAV terminal and flown away.

Thanks for the clarification!

Can player-controlled drones also be jammed by the spectrum device and give them the effect of visual degradation as long as the jammer is active, or is that behaviour only supported in the new omni-directional jammer?

I thought about this for a while. But jamming the RC uplink and the video downlink are 2 separate jamming tasks. The omni-directional jammer is meant as the big gun that does multi-band (or multi-application) jamming. I did not extend the current functionality of the spectrum device for the following reasons. In order to degrade the video downlink the spectrum device would need to be pointed to the drone pilot, not the drone (if a somewhat realistic implementation is the goal). But so far the drone pilots location is not knowable for the spectrum device operator. It could be added that drone pilots are also beacons, so that their location or at least heading could be deduced, but for now I left this out.

Yeah, that makes sense and is a fair interpretation. As mentioned in an earlier discussion I am sometimes a bit unsure about the balance of somewhat realistic implementation and gameplay loops. But I think this strikes a fair balance of just having the C2 link be jammable with the spectrum device.

But I think what I am currently missing is a forced disconnect from the drone of any controling player when the spectrum device is jamming the drone. Because right now the AI manipulation should be totally ignored by player controlled drones, which makes no sense. Thanks for the question that uncovered this gap. 🙂

Glad my questions helped! :D

btw, as you might have noticed I added a new wiki for this mod based on mdbook. I have moved over the old wiki stuff and added a bit more. Please include some documentation on how the new jammer works, or is used. Essentially the description and images you have in this PR would do nicely ;-)

Sure, I can give it a look. 🙂

Would be much appreciated!

I added a few comments, very few code changes, mostly optional suggestions or ideas. Thanks for your big work in adding this to the mod. I quite like the look of it and I am sure players will like the additional features and effects you have added! :)

[b-mayr-1984]

• might make sense to move all the jamming out of main pbo and into a jamming pbo.

That might be a beginner question: What are the advantages of separating the functionality into different PBOs?

I noticed that I sometimes struggled when the jammer functionality was spread across main and spectrum. Not only did I need to #define DISABLE_COMPILE_CACHE twice but also the macro handling like GVAR vs. EGVAR etc. was confusing at times.

[Crowdedlight]

• might make sense to move all the jamming out of main pbo and into a jamming pbo.

That might be a beginner question: What are the advantages of separating the functionality into different PBOs?

I noticed that I sometimes struggled when the jammer functionality was spread across main and spectrum. Not only did I need to #define DISABLE_COMPILE_CACHE twice but also the macro handling like GVAR vs. EGVAR etc. was confusing at times.

For this case mainly just structural in being easier to find and figure out where behaviour is defined and to not have 60+ sqf files in the same folder for all the different features. Technically you could delete individual PBOs from the mod, and then it just wouldn't load that part of the mod. Like deleting the "medicals" pbos from ace. But this mod is a tad too integrated with itself to assume that would work 😅

Its more that afterwards I learned that "main" is often more used for common functions, variables or stuff shared across pbos/modules.

I am not going to change it now, it was more if we start having fairly more features added regarding jamming, it would make sense to move it to a "jamming section" organisational.

Fair point about it being more confusing when split up, I am obviously biased from making most of it, to just know and assume where stuff is. 😅

I should probably figure out if I can get it working setting a single #define DISABLE_COMPILE_CACHE in "main" and then it works for all of them. Technically that should be the case as I believe each script_component.hpp should #include back to the one in main. But I have not tested it.

GVAR vs EGVAR also took some time for me to get used to. But kinda like it now, as I find it better using that then remembering to use "external gvar" or "quoted gvar" with EGVAR and QGVAR.

[b-mayr-1984]

btw, as you might have noticed I added a new wiki for this mod based on mdbook. I have moved over the old wiki stuff and added a bit more. Please include some documentation on how the new jammer works, or is used. Essentially the description and images you have in this PR would do nicely ;-)

You can see the current version of the new wiki here: https://crowdedlight.github.io/Crows-Electronic-Warfare/

You can add new pages in folders or new folders if necessary. Then add them as pages to the book by editing the SUMMERY.md file.

If you want to test it locally, you just need to install "mdbooks" with cargo install mdbook and then in the root of the repo just go mdbook serve and you can see your current state in localhost browser. (Requires you got Rust/Cargo installed)

I followed your hyperlink and then used the Suggest an edit button on the upper right corner to add my changes (see 8e91a5ba162cf03e47cabce5f9d063f6e930b830). This however branched off from main again (sorry for the inconvenience 🙄)

[Crowdedlight]

I followed your hyperlink and then used the Suggest an edit button on the upper right corner to add my changes (see 8e91a5b). This however branched off from main again (sorry for the inconvenience 🙄)

No worries. Is my own fault for how I configured the wiki. 😅 Considering right now to move to remove develop, and just have "main". As the releases are done in tags anyway. Would make it a bit simpler in future. Not completely sure yet though 😅

[b-mayr-1984]

Considering right now to move to remove develop, and just have "main". As the releases are done in tags anyway. Would make it a bit simpler in future. Not completely sure yet though 😅

I would very much appreciate that. 🙂 A lot of tooling is simply expecting this as the standard workflow. And that is also what most developers are used to.

[b-mayr-1984]

We did a test with 3 people on Gruppe Adler infrastructure today. There is still a bunch of problems with the features of this PR. Mostly JIP and locality issues.

• [ ] activation/deactivation state of omni jammer is not JIP safe
• [ ] jamming of autonomous drones with the omni jammer does not work at all with a dedicated server (probably due to locality issue with the drone)
• [ ] jamming of player controlled drones with the Spectrum Device does not work on dedicated server. No disconnect happens, even though the disconnect hint is displayed. (suspected locality issue)

[Crowdedlight]

Considering right now to move to remove develop, and just have "main". As the releases are done in tags anyway. Would make it a bit simpler in future. Not completely sure yet though 😅

I would very much appreciate that. 🙂 A lot of tooling is simply expecting this as the standard workflow. And that is also what most developers are used to.

I have no arguments to not do it like that 😅. So I will do that in future. When this PR is merged I'll do a merge into main, and stage everything from main in the future.

In regards to the locality and JIP issues. I'll have a closer look at the communication flow. not JIP safe, do you mean that players joining as JIP don't get affected at all? Or how does this express itself? (I'll have a look to see if the event broadcast is using Server/global events, or GlobalJIP events)

When you say: "omni jamming of drones doesn't work at all on dedicated server", Is that then the AI part?

Hmmm, odd, as when I checked the disconnect command for player controlled UAV it is global effect and global argument, so I would expect that to work no matter the locality.

[b-mayr-1984]

In regards to the locality and JIP issues. I'll have a closer look at the communication flow. not JIP safe, do you mean that players joining as JIP don't get affected at all? Or how does this express itself? (I'll have a look to see if the event broadcast is using Server/global events, or GlobalJIP events)

Players that joined at mission start share the same status of the jammer box. Players who JIPed had the box in a different state (l

• meaning opposite of open or closed with regards to earlier players
• where some players had a closed box and no sweeper in the spectrum others saw the sweep
• restart mission with all players ready at the same time fixed it.

When you say: "omni jamming of drones doesn't work at all on dedicated server", Is that then the AI part?

Yes. That is why I wrote autonomous drones .

• The drone does not change behavior when flying through the area denial zone.
• Also the 3D in Zeus mode does not show a JAMMED indication then.

Hmmm, odd, as when I checked the disconnect command for player controlled UAV it is global effect and global argument, so I would expect that to work no matter the locality.

Same here 😕 I also saw a bunch of error messages in the server RPT that related to UAV objects that it couldn't find. Could be related to this issue.

[Crowdedlight]

Yes. That is why I wrote autonomous drones .

Sorry, didn't catch that part. Thanks for clarifying that it was both behaviour and no jammed text.

Same here 😕 I also saw a bunch of error messages in the server RPT that related to UAV objects that it couldn't find. Could be related to this issue.

Might be some special cases around the uav terminal and locality.

I will try to have a look tomorrow see if I spot anything and try to see if I got time this week to load it up on our server and play around with.

[Crowdedlight]

When the major restructuring work has been merged from https://github.com/b-mayr-1984/Crows-Electronic-Warfare/pull/1 Then this should be ready for merge.

The patch has verified working code tested on dedicated server.

The only think that could be nice to add in this PR before merge, would be updating the wiki with the changes from the new drone behaviour and options.

[Crowdedlight]

@b-mayr-1984 Would you have time to update the wiki with the changes this PR makes? Like just your changes to the jammers and addition of omni-directional jammer. So there is some documentation on players can get jammed now etc.

Was already done, I was being a goofus and had forgotten about it

[b-mayr-1984]

@b-mayr-1984 Would you have time to update the wiki with the changes this PR makes? Like just your changes to the jammers and addition of omni-directional jammer. So there is some documentation on players can get jammed now etc.

You can find my Wiki changes here https://github.com/b-mayr-1984/Crows-Electronic-Warfare/commit/8e91a5ba162cf03e47cabce5f9d063f6e930b830