First of all, I'd like to thank you for the detailed reply.
IV/JG7_4Shades wrote:
The SEOW tool was designed to be a simulation of the situation map rooms that we all saw in the movie "Battle of Britain", where radar readings from many stations was aggregated and displayed in near-real time on a large map. What Riddler is proposing, I think, is a dedicated readout display of a single radar station, and judging by his prototype, it will be a gorgeous tool.
Yes, you're absolutely correct I wish to simulate individual radar stations.
IRL "situation map" is drawn by operators on a transparent wall map or as we have seen in the BoB horizontal table map where flags representing enemy and friendly formations where placed. It works similar even today, although data is displayed on computer displays. Something like this:
- Radar console operator detects a contact, cross checks with the tactical situation display and if he thinks it's a newly discovered contact passes it to identification officer (by clicking on the radar plot which also engages auto tracking).
- New unclassified target pops up on the tactical display of the identification officer's screen. ID officer can see if the con matches one of the secondaries (transponders) or already tracked targets.
- If it does, he notifies the operator to stop tracking it, if not, operator keeps tracking the target (basically just making sure autotrack is working, and helping it if necessary where there is a lot of noise, clutter or if radar is being jammed).
- Tactical situation is automatically distributed to other units, navy ships, AA batteries, ground units etc.
- Our S-600 had a malfunctioning altitude measurement equipment (magnetron out of order, and since they were about to be replaced with AN/FPS-117 they deemed repair was not worth it), so we improvised by manually slewing an old russian PRV-9 altitude measuring radar to the azimuth of the contact, and manualy imputing altitude data to the tactical.
Oops, I think I digressed a bit
IV/JG7_4Shades wrote:
1. Station ID information will need to be written to the output (*.rad) files. Presently the files look like:
Code: Select all
RADARGROUND 1 0 220626.28 329131.3
RADARGROUND 1 1 224517.48 329281.06
RADARGROUND 1 0 213088.48 307721.03
RADARGROUND 1 0 196478.95 297859.38
RADARGROUND 1 1 206278.64 298340.7
RADARGROUND 1 0 179613.02 280089.88
RADARGROUND 1 1 214333.94 263726.2
RADARGROUND 1 0 209975.12 245864.58
RADARGROUND 1 0 180929.56 231875.69
RADARGROUND 1 1 175409.73 227311.62
RADARGROUND 1 0 158495.9 221602.81
RADARGROUND 1 1 154370.34 216602.28
RADARGROUND 1 0 111026.66 221711.97
RADARGROUND 1 0 79639.42 205765.14
CONTACTGROUND 1 2 211949.8 242376.92 2000.0
CONTACTGROUND 1 2 211104.02 240746.95 2000.0
CONTACTGROUND 1 2 211857.53 241645.77 2000.0
CONTACTGROUND 1 1 210516.66 244748.66 2000.0
CONTACTGROUND 1 1 210748.42 240800.67 2000.0
CONTACTGROUND 1 2 209307.55 241976.25 4000.0
CONTACTGROUND 1 2 209911.23 241443.64 4000.0
CONTACTGROUND 1 2 210234.39 241537.66 2000.0
CONTACTGROUND 1 2 210557.28 241275.39 2000.0
So you can see each of the active radar stations (RADARGROUND), but they are not indexed uniquely at the moment. Also you can see all the radar contacts (CONTACTGROUND); Riddler will need to know which radar station detected which contact - see next point. The 0, 1 and 2 fields variously indicate the type of radar (long/short range), nation of the radar and the nation of the contact (IFF).
2. In order to reduce the server overheads, Manu used a "first detection" model, which I maintained in the upgrade. In a loop over all operating radar stations, the first time a particular aircraft is detected the loop terminates. Thus, there is no averaging of information from multiple stations for a particular aircraft which would actually have been possible. This is fastest, but has a problem in that tracking contacts for a particular radar station is not guaranteed, as it depends on the looping order for radars and their spatial coverage etc.
For the input data, each radar station would need to be indexed, so something like this:
Code: Select all
RADAR_A 1 1 224517.48 329281.06
RADAR_B 1 0 213088.48 307721.03
RADAR_C 1 0 196478.95 297859.38
RADAR_D 1 0 206278.64 298340.7
Also, there would have to be a way to notify the radar client if particular radar station gets destroyed. It can be made in the same format (in order to keep it simple):
Code: Select all
RADAR_A 1 0 0 0
RADAR_B 1 0 213088.48 307721.03
RADAR_C 1 0 196478.95 297859.38
RADAR_D 1 0 206278.64 298340.7
all zeroes on the radar site position = out of action
For contacts, I'd like to have additional info on the object game type because I planned to implement target RCS, client would show larger plots for targets with larger RCS, so say B-17 will be detectable further away then single engined fighter or at least show as a larger "blip". Something like this:
Code: Select all
CONTACTGROUND 1 2 [B-17G] 211949.8 242376.92 2000.0
CONTACTGROUND 1 2 [FW-190A8] 211104.02 240746.95 2000.0
IV/JG7_4Shades wrote:
Now, in terms of actual use, the new tool would have to have access to the RadarLogs folder. I think Charlie has found that radar logs may be written to all clients simultaneously, and this can affect game performance, so often the RadarLogs folder is disabled on the clients. It might be an idea to consider embedding the application runtime in a web page, so it can be deployed as a server tool for people to login to remotely (like the SEOW radar tool).
The client based radar would probably reduce the load on the server, client would calculate the detection envelope (range, altitude, possibly elevation angle). Server would just need to dump all the objects to a file and make it available in some way.
I'd be gathering data by calling a web service or downloading files whichever you think is the easiest to implement.
That's it for now, I have to get back to my RL work
(((. I'll post the updated WIP shots when I get home.
