Falcon

It is not only disputable, but wrong. Please, ask SMEs serving in that tank to verify, if you have doubts about it. Your depiction of that issue comes from misunderstanding of the training manual (see the text above) combined with prejudice from some pictures, perhaps personal experience from sitting in one of them. However, there are multiple occasions showing real combat usage when TC is clearly using both TIS and Peri. Besides that, Your current depiction of that issue strictly (and artificially) limits usage of the vehicle in your software. I would appreciate you looking into it, as it is an unrealistical limitation in your simulator. Thank you

Does T-72B3 TC in SB still need to turn Peri 180° away in order to use TIS?

Any update on this issue?

Happy to take B11 (and control B1 AI Plt, if need be). Scratch that. Sorry for troubles MD

Well, my point of view is perhaps more from civilian point of view, that every tank has TIS on one key-bind. I understand that for military application, uniting this might cause a problem when trainees would think they can use that specific instrument for a function it doesn't have. But then there is the question if there is any military user using B3 to train his tank crews inside of it. I (perhaps naively) think not, thus my belief that it should be unified in order to ease "non-T72B3 Obr.2012 users" controls of this tank.

Okay, fair point, if that key-bind is used in other vehicles in SB as well, I've never used it before. Although, I believe it would be easier to have TIS control binds standardized across all tanks in order to ease the transitioning between them, but fair enough.

Thank you for answering to what I was asking for. Now we can stop wasting each other's time and start talking about this issue. You correctly mention that Paragraph 4.3.5 tells TC to turn cupola right, but did you read (and correctly translated) the whole guide? Does it mention any reason for this step? Why in SB it has to be turned 180° backwards even when you don't want to change settings on your PU TK console or want just to look to the display? - I note that PU TK is the console (responsible for setting up TIS display) behind Peri, which is the point of the whole issue as everything else is clearly in TC's reach no matter the position of Peri. Here is one publically-available version of the guide [1]. After reading the whole guide, it is clear that your mention of urge for TC written in Paragraph 4.3.5 is a redundant note serving as a reminder in case TC forgot to turn on or set up his TIS display in previous steps prior the combat. You correctly say, that that cupola has to be turned to the right side for TC to be able to reach PU TK controls [2], but common sense tells that he doesn't need a full 180° swing to reach for that switch on top left corner of the PU TK [3], especially in combat situations where time is crucial. Furthermore, visual settings of Contrast, Brightness and Sharpness on TIS can be set also by "+" and "-" multifunction buttons located on TIS display. It is my understanding that only Field of View ("Zoom") and turning on TIS display can only be switched on PU TK. I add, that turning off "DOUBLE" mode (thus switching FCS back to MAIN) can be done by turning off DOUBLE mode in PU TK [3] and switching DOUBLE OFF in PK72 console, as it is mentioned in Paragraph 4.3.7. One could even speculate that there is still some space for some buttons on PU TK to be pressed while Peri looking forward, but I will leave that to real-life T-72B3 crewman to answer it. Setting up PU TK (TIS display settings) can be and should be done prior the combat. That is the only reason behind the need of moving Peri away (and can be done only as much as needed, not whole 180° swing). There is no need to change the settings while in combat, TC can still use his TIS display. Moreover, combat footage clearly shows that it is possible for both AFU and RuAF TCs (main users of this tank) to have Peri looking forward while looking at his TIS display during engagement. Current SB puts here artificial restriction, which severely limits the tank capacity. I see no reason behind this artifical restriction and I think it has no place in a tank simulator. Notes: [1] Source for version of guide I used: https://vod-str.ru/tankovaja-uchebka-dejstvij-jekipazha-pri-rabote-so-stabilizatorom-t-72/ [2] Paragraph 4.3.5 (ENG trnslation: " 4.3.5 Switching on the "DOUBLE" mode The switching into the "DOUBLE" mode is possible from the commander's seat when the FCS is operating in the "MAIN" mode. To enable the "DOUBLE" mode, you must: - turn the commander's cupola to the right to provide access to the PU TK (TC's TIS control console located right behind Peri); - set the mode switch on the commander's PU TK to the position "[picture]" (on); - after removing the cover of VSU (TIS), set switch 6 (Figure 7.27) of the "DOUBLE" mode on the commander's console PK72 to the desired position (B, K, O, P, U), while on the commander's console PK72 the indicator of the activation of the "DOUBLE" mode lights up, a yellow light signal lights up in the lower part of the field of view of the optical channel of the Sosna-U PNM, and on the VSU indicates DBL. " Original text: [3] Picture of TC in T-80BM. PU TK is placed on the side, but it is the same console. This switch has to be pushed to the most upwards position in order to engage DOUBLE (along with PK72 switch 6). Notice the great visibility of TIS display and how much is the cover opened. I don't want to open another discussions with two very similar topics, so I will post them here, they are rather straight-forward. 1) TC's TIS display cover should be more opened and not be obscured from F1 position view (which is two staged, currently there is only a high position in SB). Here is a picture showing TC's eye-level from low position when sitting on his seat. Not ideal, but still visible even with Peri looking forward. 2) Is there a shortcut for Gunner in T-72B3 to look through his TIS display? I can't find it and looking everytime down-left takes with mouse and keyboard unrealistically huge amount of time. If not, perhaps Num+ while in GPS (with perhaps a slight time-delay, should you want to simulate that head movement). - edit: Answered by @Arch, key-bind is Alt + F2. I am happy to have the discussion if it should be unified with the rest of tanks where it is Num+, though. Thank you

I am missing the point of your argument. There are multiple evidences that they use TIS without even rotating Peri to the side (not even talking about whole 180° rotation currently depicted in-game). Although it is a crammed space, tankers (operating ex-soviet tanks) have height limits. At least in my country and in all others I know which were/are using them. But that should not be important as I believe SB is a sim based on facts and not opinions.

Hi, I always wondered, why in Steel Beasts, T-72B3 TC has to rotate the cupola periscopes in order to see through his TIS. I still can't figure out why is that, as I saw multiple pictures of various T-72 tanks (although not exactly T-72B3 Obr. 2012) where TC is able to use both cupola periscopes and TIS. Is there a real-life source behind that behaviour in SB? This requirement very limits TC's spotting capabilities. Here is one pic example of using TIS while having Peri looking forward. I am glad for any information, or reasoning why is that so, thank you.

Hi, unfortunately I won't be able to join your events for unknown time. My current training schedule overlaps with them.

Count me in

We have national holiday, so I'm free from work and thus will be there.

Count with me.

No issue when playing the same scenario Offline, my PC hardware is thus not the issue. CPU avg. usage was ca. 30 % (no difference between Online session). I was switching seats and tanks a lot, no observeable spike unless I went in GPS and was looking at burning MechInf Coy. (which is expected, a lot of effects has to load, and even then it was a spike to 40 %). I don't think that Host's Server hardware is the issue as well, as then everyone in the sessions would experience this issue. I am out of ideas. If there is anything I can do/test, let me know.

Today, no visible issues. Debug reports only 2x Error regarding High Ping (3-4s) and 2x Error regarding artillery Smart ammunition (note 1). This error was not previously noted, however it doesn't look as a cause for these issues. If needed, let me know and I will send a link for Debug, AAR and Scenario file. Leo2A5 Same host ca. 110min scenario note1: Error line from Debug: [21:32:15,536] CGame ERROR: A nonimpotent CHEArtySplash was created for ammo: HEAT-EFP-SF 'SMArt DM702'^ note2: Scenario had lower amount of units in comparison with those with networking issue. Tomorrow, I will test the larger scenario in Offline in order to observe any unusually high CPU usage or spikes of it.

I'll be there

The problem repeated today. Leo2A6 120min (issues from T+70min) Same host Kaspersky Free Antivirus + VPN OFF (checked multiple times via Task Manager before, during and after the Online Session) If I will have time tomorrow (I have busy 4 days ahead), I will do a few things (play the scenarios in Offline Session, check AARs, go through Debugs, ...). However, the problem appears to be connected with CPU usage. There are moments, when all my 8 logical processors went into 100 % for a brief moment (2s). I was checking it live with Debug and it started to cause the High Ping Errors. The high CPU usage appeared on these occasions: Switching positions: TC <=> Gunner Map => 3D View and when working in Gunner's seat: F1 <=> F2 (WHOT, I didn't test other regimes in GPS) I didn't noticed this issue in TC's position. GPU usage spike to max 50 % This time, the session was better at re-synchronizing. The High-Ping Errors in Debug were successfully "extinghuished", however it had a permanent effect on synchronisation on the battlefield (Red wrecks were not visible on my PC). I will investigate AARs later and report back (or let me know and I can send them to you). Perhaps it is my subjective bias, but I can't remember these issues prior the "Thermal sights update", which was released a few months back. I wish I could give you better feedback about this, but I started to play regularly SB since last November (I've played 2x30 days in last 2 years). Anyway, I will report back later during the following week. note1: Here is the visible CPU spike after switching from Map into 3D view. Unfortunately I didn't have the opportunity to measure this when inside my own tank. My HW specifications are visible there as well.

Is it possible that invalid ID unit was a Redfor unit? I've noticed my issues at ca. T+01:29:50, I was engaging remaining vehicles of Red BMP platoon. The same group was already engaged by Gladiator and Gibsonm, who didn't report any issue. I was re-checking AAR. At T+01:29:46 my tank is shooting (dust is up and gun is elevated in order to reload). But both mine and Gibsonm's AARs doesn't register any hit. Gibsonm's AAR register only a BMP kill at T+01:30:01, which is not showing on my AAR (as I've written here previously). I didn't notice nor recall any interaction with Civilian units. I remember that I saw a few of them on the map at the beginning of the scenario. Later on, AAR shows that there was one bus driving in the same town as were tanks under my control (A and A3), but the bus was not even in the same street so there shouldn't be any collisions/interactions with that unit. From my limited experience with software, even a rather small error can cause instability in the system. Although I don't observe any instability issues of my PC/OS, this error could potentially be the trigger causing this. It is also interesting the specificy of issue - 90minutes, Leo2A4 and Abraxas's server as a session host. So far we didn't manage to recreate the problem at other time or in different vehicle. If there are any ideas what to test next-time, let me know. I am happy to help as much as I can, as this is quite limiting issue for me.

Count me in. I've prepared plans for the next scenario, in case we finish the current one.

@mrivers We've played 90 minutes long scenario with Leopard 2A4 (from circa 20:30 to 22:00) I'm sending you the link to the RAR file, which contains my DebugLog, my AAR, @Gibsonm AAR (we were in same platoon) and the scenario itself. https://ufile.io/36iqc9lv What I've observed: - in-game desync behaviour in the last circa 10 seconds (delayed seat-switch control inputs), only on my side - DebugLog shows high-ping errors (8-12s) in the last circa 4 seconds - no MYMSGID_BUILDINGMOD, but a single warning of MYMSGID_ASSIGNEMPLACEMENTS at 20:57:44,798 - a lot of warnings about null IDs (perhaps scenario related?) - my and Gibsonm's AAR looks same up until the very last second: At 1:30:01, Gibsonm's AAR reports me destroying vehicle (5/021). My AAR doesn't show this hit and at it's end (1:30:04) the vehicle is alive. I remember that my gunner was shooting at something at the very end of scenario. At that moment, I was already having the delayed control input issues. This corresponds with this error message in the log, which reappears even when looking at AAR: [22:04:14,556] CActorListArray WARN : Tried to retrieve combatant with NULL ID! Before starting SB (and joining the session), I've disabled my Kaspersky's protection and quitted the application. However, Kaspersky Secure Connection application was still running on the background (I've noticed that after the session). It is a VPN connecting tool, which I am not using - I've double-checked that. So, it is replicable, possibly connected to Leo2A4 (I want to test this next session, since it happened twice in a row at +- the same time) and Kaspersky Free Antivirus might not be the cause, although that VPN application running on the background could have do something - I can test it being turned off as well. However, to test it properly, I think I will have to uninstall it. But that is the step which I'm really not happy about and I would consider it only as the last resort. Kaspersky serves me and all my friends using it very well and I don't trust "naked" Windows to defend itself on nowadays internet. note: That last second vehicle destruction looks weird to me. I understand that at the end of online session, things may go haywire, so it might not be important at all. But why Gibsonm observed destruction and I didn't, when it was my tank destroying it? That suggests to me, that although my reported high-ping, information from my PC reached host. But perhaps the return ("destruction/hit confirmation"?) didn't reach my PC back? Anyway, looking forward for the answer.

Unfortunatelly, I didn't save my AAR. Today, we are having another session (and with Leo2A4 as well). I will report how it went (and save AAR, just for a good measure).

I'm not sure if you are still looking for some additional information. If so, you may find this video interesting. It is based on the captured manual, with some additional information.

I've asked @Abraxas If I understand the answer correctly, they are on the same machine.

The TS server and SB server "applications" are running on the same machine In the next session (Friday), I will try to disable my Kaspersky Antivirus. Maybe it is the cause.

Thank you for looking into it. I've attached the scenario file to this message. It is from my .../My Scenarios/downloads/ folder, so it should be the exact played scenario version. - a question: Should I delete the file from this forum discussion when this issue is solved? I was told that it is better to do so in order to not use the forum "disk space". I will ask the host if the TS server is running on the same PC (or some local one) as the SB sessions. However, when I'm in the lobby of these sessions, my shown ping time is approx. 10 - 20 ms, which makes sense since we are from neighbouring countries in Europe. It is perhaps interesting to note that I can join and play even when the host (different one) is across the world (with ping time approx. 300 - 350 ms). Only with the visual "vehicles teleportation" happening from time to time, which is expectable with this ping and is always "automatically re-synchronised" after max. 2 seconds. I have a debug file for one of these sessions as well. It has only a few (6) Errors "Ping time too large" with maximum ping time 2 s. Then there are a lot of warnings about "forcing monotonic mission time" (same as in the problematic session).