Verbose logs

[Paul Vebber]

Been lurking a while, and seem to recall a way to get "all the die rolls" for detection, weapons, etc logged, but cant find it. Is there still a way to do that in the commercial version, or is it just in PE?

Thanks,
Paul

[FifthDomain]

if you want it to put stuff in the logs use the following: (In-Game) Game >> Game Options >> General >> Tick Box "Log debug information to file (for debugging only)"

If you want stuff to show in the message log use the following: (In-Game) Game >> Game Options >> Message Log >> Tick Boxes to show on messages in the log. Then in top left hand corner of the Message Log Display press the >Raw button this will give more detail which i think is the bit you want.

[Paul Vebber]

Ill give those a try! Thanks!

[Paul Vebber]

Turns out that's what I had and in a ASW test scenario only get the initial detections

10/3/2023 2:30:46 AM - [Red] New contact! Designated SKUNK #1 - Detected by Type 093B Shang [Sensors: Generic Acoustic Intercept] at 93deg - Estimated 69nm

10/3/2023 4:13:08 AM - [Red] New contact! Designated GOBLIN #2 - Detected by Type 093B Shang [Sensors: China SJG-206A TASS] at 94deg - Estimated 16nm

10/3/2023 4:13:13 AM - [Blue] New contact! Designated GOBLIN #1 - Detected by SSN 792 Vermont [Virginia Class, Flight IV] [Sensors: AN/TB-29] at 275deg - Estimated 16nm

10/3/2023 4:13:38 AM - [Red] Contact: GOBLIN #2 has been type-classified as: SSN (Classification by: Type 093B Shang [Sensor: China SJG-206A TASS] at Estimated 3 nm)

10/3/2023 4:13:43 AM - [Blue] Contact: GOBLIN #1 has been type-classified as: SSN (Classification by: SSN 792 Vermont [Virginia Class, Flight IV] [Sensor: AN/TB-29] at Estimated 5 nm)

10/3/2023 4:23:19 AM - [Blue] Contact: SSN #1 has been classified as: Type 093B Shang - Determined as: Hostile (Classification by: SSN 792 Vermont [Virginia Class, Flight IV] [Sensor: AN/TB-34] at Estimated 2 nm)

Now when I click on the enemy unit, there is a whole series of detections scrolling along every few seconds. Is there a way to get that stream of information in the log? What is generating them? Are there dice rolls associated with them? Myself and a few others are trying to understand what is going on and why sensors seem to always detect at exactly the same time if you )with a few minor outliers?) when you rerun a scenario making sonar appear to be "cookie cutter" sensor when it should have a LOT of variability run to run?

Thanks!

Paul

[Dimitris]

Hi Paul, it's been a while!

Turns out that's what I had and in a ASW test scenario only get the initial detections

[.....]

Now when I click on the enemy unit, there is a whole series of detections scrolling along every few seconds. Is there a way to get that stream of information in the log?

As you said, the message log shows only the initial contact-generation detection, not subsequent detections on the same contact. To get details on those you need to use CPE and look into the "UnitDetections" export file.

What is generating them? Are there dice rolls associated with them? Myself and a few others are trying to understand what is going on and why sensors seem to always detect at exactly the same time if you )with a few minor outliers?) when you rerun a scenario making sonar appear to be "cookie cutter" sensor when it should have a LOT of variability run to run?

A "fuzzier" range limit for sonar checks is one of the top items on our (ever-expanding) package of planned underwater warfare improvements. This was the original list: https://www.matrixgames.com/forums/view ... 8#p4790358

You may remember we discussed some of these in-person, and since then the list has also grown considerably. One of the key items, a fully-reworked sonar model, has been under development for some time now, but the other items had to be temporarily set aside in favor on focusing on Tiny, ATO compliance and RTMP. Now that the last few big mothers are maturing, we'll hopefully be able to devote more time and resources on that list. Are we correct to assume that the fuzzy limit is high on your priorities?

Thanks!

[Paul Vebber]

Hi Dimitris!

Ya, long time, but questions have been crossing over from "personal interest as a fan of the game and how to improvev it" to "my day job for the Navy and folks using CPE, but not being analysts or gamers, have trouble figuring out how its behavior maps to their reality" so decided to re-engage here and ask I mentioned to Iain at Connections UK that I'm a bit less than a year from retiring and doing a bit of "test retirement" going to more wargame cons and such. Re-engaging here is another "test opportunity" (though fo some of this email might be easier... paulwvebber@gmail)

The issue is not just "fuzzy-ness" but the right sort of fuzzy-ness derived from the stochastic nature of many of the terms in the sonar equation. And the logarithmic nature of dB math (3dB doubles or halves the range, and the "medium term" (several hours) std dev in "all the randomness" is 6-9 dB. Thus the reliance on "50% probablility of detection range", which the "consistent 100% detection range cookie cutter model" violates. This gets to why the experimenting with the Naval War College ended up faltering.

The current "contact development" of "Goblin --> Type class --> Hull class --> Hull ID. Is fine for surface ships, (well even there "Hull ID" gets increasingly problematic), passive "Hull ID" in a "tactical context" is not nearly as important as esblishing a track (course and speed estimate) which requires Target Motion Analysis (and some manuevering) over much longer time frames than currently reflected. Better would be "Goblin with bearing only" - just leave off the always "est 16nm". --> Goblin with initial range (need at least one manuever typically (less important with flank array) to get decent range to get course and speed by TMA). --> Goblin with better range and an initial course and speed. About this time you probably get a "Hull class" (there is typically no way to get a "type class" distinct from "hull class" as the tonal muances that destinguish class are exclusive to that hull type and not shared "with other SSGNs". No one is ever going to confuse an OHIO SSGN and a Shang 093G SSGN... just get rid of that level of "classification". Finally after a couple more "TMA legs" or integration time on the flank array, you get a "fire control quality track" and a good probability of successful torpedo attack. Now advanced sensors like a flank array let you combine bearing data from it and other sonars like the towed array to get a much better range estimate than just the Tail (or sphere) without the TMA leg. But with messages focusing on "hull class --> ID rather that contact --> range --> track --> fire control solution. The game doesnt communicate the data of interest to the player.

The "integration time" processing data to create a waterfall display varies with range from a few to several minutes and the speed of sound in water (about a mile a second) means that a single ping out to a CZ takes about a minute out and back and it takes some "M of N" fraction acrossva series of pings to establish a course and speed ising active (and is really bad at Class). So a few to several (or quite a few if multiple CZs) minutes to get to "track" which enables an effective torpedo shot. You get contact and lose contact at shorter and shorter intervals as the range closes and if the target zigs, you have to "start over".

The current "cookie cutter effect" makes this all happen far to quickly and "repeatedly reliable". But trying to "compute it all in real time" is a huge processing sump, hence my advice to go a bit more "abstract" in representing these effects as being "more realistic" than "adding more calculation" that gets you in effect "more precise, but less useful" in the George Box "all models are wrong but some are useful" sense. Yge 2nd partvofvthe quotevis to the effectvof "and cannot be made so (less wrong or more useful) by excessivevelaboration". Dont spend CPU cycles focusing on more granular level of ID, when the "real goal" is range, course and speed! And the fact you are always operating with a perception of those variables some number of minutes old that makes folks see the game messages and time stamps and scratch their heads asking "whats goin on in there??"

As in our face to face, my desired solution would be less focus on individual sensor detection data -avoid the trap of "more fuzzy detail" and instead on detect --> class --> ID. Focus on determining and communicating a more holistic "how good, given my different sensors and my ability to fuse them onboard, is my current progress from detect to fire control solution?". That "track quality - centric" approach can also be of great use in ASuW as more and more "OTH sensor fusion" enables fires than individual sensor detail. But that requires a C2 model...

All the best!!

Paul