I understand this with regards to live testing a map patcher and was not advocating this in the slightest, although it may have seemed that way when I posed the question, they were two different things really.
I will share what I have thought about here and see what ideas come out of it.
First one with regards to testing the map.
Map Hole finder
Viewport_Hole_Test {to test where textures and mesh meet or not as is the case for holes.}
This would have to use the grids within the map and test each one and publish hits to {Hole_Found}
Hole_Found would store the exact coordinates within an array and publish this,using ue4’s ( Observer Pattern)
A seperate viewport could then subscribe to the coordinates that have been published by the previous viewport to go and determine if it can do one of the following
Condition 1: either use a placeable within the hole that can be used to store items or a respawn point for player. (Already in the game)
Condition 2: be used for placing foundations in, and in turn placeables or spawn points for players. (Already in the game)
Hole_Build_Tester:
If
Either Condition 1: either use a placeable within the hole that can be used to store items or a respawn point for player. (Already in the game)
OR Condition 2: be used for placing foundations in, and in turn placeables or spawn points for players. (Already in the game)
Then Call Fill_Hole
Return
Fill_Hole Would subscribe to Hole_Found and allow devs to do what they do when patching holes here.
The second with regards to a realtime reporting system:
Realtime chest detector:
Using the existing funcionality within the game that allows you to report a player this could also call {ShowPlayers}
The reporting player would then select the player that he has seen cheating this could then be published using ue4’s ( Observer Pattern)
The admin viewport could then use {ToggleDebugHUD} to retrieve the information regarding the player and could then call {Invisibility} folowed by ViewPlayer [PlayerName] which it has subscribed to.
This could then actually watch the player and record with exact coordinates and timestamp what the player is doing from the playeers perspective.
It would then determine based upon criteria already in the game (as to undermesh,one kill,lag switch)
Lag switch could use the players ping and the distance between the reported player vs distance to killed player to determine based upon internal game values whether this is indeed lag switch or bad ping.
If this distance is not within parameters of the game taking into account the ping then it could set a flag
The flag could then store this as a possible lag switch one hit kill and could then continue to watch the player to see if this is a one off or a repeat.
If the suspected player again does this then the flag is set again and maybe third time the player is disconnected from server.
It could then inform funcom via the reporting ability within the game that this players actions needs investigating as a possible cheater.
To prevent overusing and spamming the reporting system a player may only report 1 time every hour or something like this a cooldown period so as not to spam the system.
This is what I meant that the mechanics for this were already in the game and were actively in use in one form or another, it would have to be done at a dev level and would not really require them to do really any content creating just reworking existing things that they already have it in place.
I apologise if I came across as a knowall as this was not my intention, my wife tells me this sometimes but I can get a bit of a one tracked mind and in this mode forget myself.
Any thoughts on above is appreciated and can either sink the ship before it sails or enhance the idea to create a viable working solution to present to funcom in the hope that they may do something with the cheats.
This sort of realtime compiling of evidence would eliminate false flag reporting, abuse of the system to get a player or clan banned, and prevent a backlog of reporting tickets at zen desk regarding cheaters on a server.