Volcano

28 OCT 2022: Firefight 79-S04-4363 Points are compared week to week (Blue is positive points and Red is negative points). By the end of Mission 10, if Blue has +500 points or more, or if Red has -500 points or less, then that side wins, otherwise it’s a Draw. On the other hand, if the points are either > +1500 or < -1500 for two weeks in a row then the campaign ends early. Also, like in the recent MBT 87 campaign, that system of Awards will be used for extra points that might influence the final outcome. Current Score: +1,464 https://www.steelbeasts.com/sbwiki/index.php?title=Firefight_79 SPECIAL CONSIDERATIONS: Draft? No. Any new players will balance out the sides as necessary. Random CO selection? No. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

Just FYI, So it seems there is still some strange behavior here in Network Session. For the past weeks we have been looking into this, and have fixed (hopefully) all remaining issues recently, for the next patch (post 4.363). In the mean time, it was expressed that a way to work around this problem is ... In Network Session, if you observe the T-72B3 FCS doing some "crazy" (like acting jittery, or as if there is some kind of conflict going on) then in the gunners position change the FCS into "emergency" [. key] and then back to "normal" [, key] and then the issue *should* resolve itself. If you jump out of the tank and back in, you might have to do it again. It seems that the HOST and CLIENT were getting out of sync with an FCS setting, and doing this toggle between normal/emergency forces a message to be sent across the network.

Yes, they are in the Teamspeak main lobby, over the weekend after they are played, and then are replaced at the start or middle of the next week.

Have you tried this? We are sort of grasping at straws here with the info available, but this would be a primary indication if the sound is being sent to another device that is not in use. Do you see any of the audio devices EQ bar in that dialog lighting up green when in Execution of SB, and if so, which one?

Thanks for playing the 3rd Firefight 79 scenario. Round of applause for DK, the MVP of the scenario. 👏🙌 Current Score: +1,464 https://www.steelbeasts.com/sbwiki/index.php?title=Firefight_79

The other thing you can try is when SB is running in a mission, open up the Sound playback dialog and scroll up and down that long list of devices you have, and see if the EQ bar to the right on any of them is "lighting up". If it is, then the audio is being played on another device. Honestly, I don't see how you can have so many audio devices in that list (it scrolls). The best thing to do would be figure out which of those might be considered excess and right click on them and disable them so that you have only the ones you actually use active. What are the names of all the other devices in the scroll list? 🤔

If you have your NVIDIA HDMI setup as the primary audio source, then the audio would be going through an HDMI cable, to your display (image its like a TV here), then to your headphones from the display. It's why I said that it would make more sense to have the Realtek as your primary audio device instead -- NVIDIA audio is really for when a TV with speakers is hooked up and there are not other means of audio. I mean what do you have your headphones connected to (what jack) and how? It just sounds like your audio setup is questionable -- you'd have to go into Windows and do a test of the audio to see what you can hear, and look at the slider settings for your audio devices. Then also, in Windows, you have a separate audio slider for each application, and should make sure you don't have SB muted. So, it can get complicated there. Either way, that doesn't explain the log file. Have you tried uninstalling and reinstalling SB?

Option A First question is, do you have any sound mods installed? If you do, then most likely there is a sound file in there that is of an incompatible type (my guess is that saved as ADPCM .wav file instead of PCM .wav file -- the most common error that people do). Then when SB tries to load it, it probably fails and just gives up loading any sounds. You can test this by going to your mods folder, and putting all files in the mods\sounds\FX and mods\sounds\voices\(whatever language you may have altered) into a ZIP file, then delete the mod files there, reload and see if that helps. If that doesn't help... Option B Now this is speculation territory here, as the previous seems more like the cause here. But, speculating -- if I am not mistaken, if you are utilizing NVIDIA device as your primary sound device, then that would imply that audio will be coming through HDMI cable (from the video card) -- which further implies that you would only hear the audio through speakers attached to the display where the HDMI connects to. If that is the case, you are far better off disabling the NVIDIA audio devices, and instead using the Realtek Audio as your primary audio device, in which case you would be connected speakers to the back of your PC via audio jack or fiber optic. The point is, you could be having audio going to a source where speakers aren't connected. Maybe try swapping your primary sound device?

Any information about your hardware? Sounds card, if any, and if not then your sound device? Windows -> Device Manager -> Sound, video and game controllers https://support.microsoft.com/en-us/windows/fix-sound-or-audio-problems-in-windows-73025246-b61c-40fb-671a-2535c7cd56c8 (general Windows troubleshooting that might help) (Other than that, you could/should probably uninstall SB and reinstall it and see if that helps, as a very basic step 1 troubleshooting attempt.)

21 OCT 2022: Firefight 79-S03-4357 Points are compared week to week (Blue is positive points and Red is negative points). By the end of Mission 10, if Blue has +500 points or more, or if Red has -500 points or less, then that side wins, otherwise it’s a Draw. On the other hand, if the points are either > +1500 or < -1500 for two weeks in a row then the campaign ends early. Also, like in the recent MBT 87 campaign, that system of Awards will be used for extra points that might influence the final outcome. Current Score: +667 https://www.steelbeasts.com/sbwiki/index.php?title=Firefight_79 SPECIAL CONSIDERATIONS: Draft? No. Any new players will balance out the sides as necessary. Random CO selection? No. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

Thanks for playing the first two Firefight 79 scenarios. As for the first scenario, I discovered that the scoring was WAAAY off, broken on the Soviet side, and inconsistent with the briefing on the US side (I had been trying to improve the FF79 scoring based off of experience from the MBT87 campaign, and I overlooked a few things there). I corrected the score and briefing then ran a test, replicated the result (destroyed 5x tanks on US side, and 4x tanks on Soviet side), and the score came out to be: US: +669.1 Soviet: -330.9 Result: +338.2 (rather than +518, which is a significant difference worthy of correction here) Normally I let the chips fall where they may, mistakes and all -- but since the score was so broken I will go with this corrected total for scenario #1. I am sure everyone understands that we cannot start the campaign's first scenario off on a broken foot. 👍 The page has been updated here: https://www.steelbeasts.com/sbwiki/index.php?title=Firefight_79

While polls are nice, I might have mentioned already in the previous pages (maybe not though?), the key tapping is mostly due to the fact that this is the only way manual AZ and EL movement can be replicated with control wheels. That is, an actual controller that has rotating wheels (the military has these, and so do some people in the community) where so many partial or complete revolutions of a wheel triggers a key press. Hence, the key tapping. You can't do this with mouse movements and there is no way around that. Someone could certainly argue that mouse AND key taps should be possible, but then that doesn't take into account nor differentiate between the inherent advantages of some systems, for example the Leopard 2A5++ manual turret control which is done through backup electric motors (IIRC), versus the M1 that relies on purely manual control handles, so its a bit more complicated of a design issue than one might think. Just because people think something is unnecessary or that they don't like it, doesn't mean that they understand all the reasons why it exists. It also doesn't make sense to base design off of community surveys, because then all of these things have to be explained when we know why they were done for a reason, or worse, we sometimes don't remember the reason. Certainly some design elements can be based off of popular opinion/polling, but making a simulation cannot be an exercise in "democracy" either (like democracy - not everyone understand what they are voting for, which is pretty bad when it comes to game design). But we also don't want to be like: "You know that poll that was done? Sorry, but not going to happen, and here is why (long explanation that might cause disagreements)." It's not nice to do. Certainly though polls can help prioritize long term improvements though, but not everything can or should be acted on, is all I am saying here. All that said, there are some inconsistencies in the design here and that is known -- such as the BMP-2's ATGM launcher that must be controlled with key taps for the tiny traverse wheels, but then the same dismounted launcher uses mouse traverse. In this particular case the mouse and key taps should be possible on both for various reasons. So if anything, the consistency should be the main issue to resolve here. 👍

14 OCT 2022: Firefight 79-S01-4357 Firefight 79-S02-4357 (Two scenarios which are both short, which will start the Firefight 79 Campaign, consisting of 10 scenarios. Once a side is chosen then participants will remain on that side until the campaign is completed.) Points are compared week to week (Blue is positive points and Red is negative points). By the end of Mission 10, if Blue has +500 points or more, or if Red has -500 points or less, then that side wins, otherwise it’s a Draw. Also, like in the recent MBT 87 campaign, that system of Awards will be used for extra points that might influence the final outcome. Current Score: 0 https://www.steelbeasts.com/sbwiki/index.php?title=Firefight_79 SPECIAL CONSIDERATIONS: Draft? No, unless the teams do not seem balanced at the start. Random CO selection? No. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

Ooops, one more thing - can you attach the HTML report file from that mission? Thanks.

It may have been covered already (I haven't read every post), but the overpressure kills from artillery, airstrikes, IEDs, mines etc are not strictly representing the crew being harmed inside the vehicle. Did some of the crew get wounded? Maybe, maybe not at all. But like the vehicle hitting a tree at speed causing a crew member to be randomly "disabled" in SB (with the probability being dependent on the tree's mass and the vehicle's mass and speed), this represents wounds that take them out of the fight from say, an injury like a broken bone or whatever. People often interpret this as the crew getting killed, but that isn't the case. Overpressure is a similar abstraction to structural damage to the vehicle (not the crew), but is far more detailed. The point is though, like the tree collisions, it is representing something that we cannot directly model within the limitations of SB. I will try to explain... In the case of a vehicle getting killed by overpressure, it primarily represents damage to the vehicle's structural integrity that occurs that knocks the vehicle out of action. What we have is a system where there is a % of a kill calculated from overpressure that depends on the overpressure force of the explosion based on the distance from said explosion, depending on the overpressure protection level of the target type. MRAPs (at three different protection levels in SB) being the best to survive such explosions for obvious reasons, followed by "mine protected" vehicles, followed by ordinary tanks, then light armored vehicles, then unarmored vehicles, and so forth all the way down to micro drones. All of these different protection levels are represented in SB. In SB this translates to a "100% threshold", that is the radius distance from an explosion that there is a 100% "kill" (destroyed) chance from the point of impact. From that 100% radius, it then rapidly decreases in probability to 0% chance over distance, the further away from that radius you get. Meaning, its not strictly a yes or no situation here, its a 100% "yes" at a certain distance, then there is distance it is possible before becoming "no", all depending on the target's protection and explosive power of the round (which in itself is calculated from many variables that even factors in the type of explosive - TNT, RDX, HMX, C4 etc.). So, the distance on what would be considered 100% is very detailed. This isn't some arbitrary number happening here, its something that is carefully handled while allowing some "chaos" to exist. The very same explosion in the image is likely a low % chance of an overpressure kill happening at that distance on that target type, of that round type, and it was by pure chance that it happened, otherwise it would have likely been a long list of non-kill damages as the result. Bad luck, if you will, but of course had it not happened then likely there would have been crippling mobility damages. So in this case, a kill occurred and this was allowed to exist in the values because we want there to be cases where it represents the "gray area" where fundamental structural damages can occur (that don't exactly include in the relatively simplistic damage types that are explicitly modeled ("engine", "suspension" and so on -- we are very limited in that regard). Actually, out of curiosity and the desire to test if everything looked OK here, I took some time to do a manual calculation to test the situation. Based off an estimate of distance in the image (based of how wide I know the M1 tank is), the 3OF-83 BB-HE at that distance comes out to something like and overpressure kill probability of 31% at ~4m radius, dropping off to 8% at ~5m radius, dropping off to 0% at ~6m for an ordinary (non-mineprotected) tank, with only a direct hit from a single 155mm HE being something like a ~70% kill chance. This means that the explosion has just barely occurred inside the non-zero radius, which is not unreasonable. And to have overpressure, which is a very complicated thing, be represented in a dynamic way that allows some randomization "die rolls", this is about as best as can be expected without it being a completely binary approach (strictly a 100% kill or 100% no-kill result). Of course someone might question the exact probability over distance to 0%, but these levels are not unrealistic here and we do not entertain subjective opinions - we instead base it off known cases to establish the 100% situation, then let the math do the rest without putting a hand on the scales. Hopefully that simplified explanation helps explain how overpressure works in SB. It is quite detailed (probably way more detailed than it really needs to be, but hey -- I think its one of the best features in SB), and it allows for all sorts of overpressure protection levels to be represented, 100% preventing an MRAP from being destroyed by the same explosion - saving its infantry inside to allow them to dismount and defend in an ambush, for example. But it allows for normal tanks to have a chance of being destroyed by near 155mm artillery explosions from IEDs (the more artillery rounds in the IED explosion the higher [but not exponentially] the destroyed probability radius). It also allows for actual mine protected vehicles to have a better chance of avoiding destruction, by decreasing the radius distance at which it drops to 0% kill, if that makes any sense, which is quite nice.

Ok, got it. I'll look at updating that page this week.

BTW, if you all did play the Battlezone then if someone can make the AAR file available to me then I will add the results to the relevant SBwiki page...

Yes, welcome back indeed. Excellent timing too, because Firefight 79 campaign starts this coming TGIF. 😎

Actually, after a discussion, we discovered that Sean and two of the backup TGIF hosts (myself included) will be out this Friday (not all for the same reason) and will not be available. So, it seems like the best thing to do is to put TGIF on hold this Friday, and resume it next Friday on 14 OCT, when the Firefight 79 campaign begins. I will leave the above scenario in the lobby, as well as the most recent Battlezone scenario, so if the community wants to try to get a game together at that time then by all means, you may use either of those scenarios if you like. Or take the Friday off and rest or go out on town. 😃 So, until next Friday the 14th...

7 OCT 2022: Border Dispute 2013-4363-FMU SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 8 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

Whoops, I missed your post. I guess you figured it out since you were there, though. 😁

30 SEP 2022: !Battle for Lawfield Corridor v14-smaller-4363-OMU SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 8-10 NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.

An update on the Firefight 79 campaign plan: I'll start it in two weeks from now, 14 OCT. This may be best anyway since I might not be available on 7 OCT anyway. So, if anyone wants to participate, then it will get going around that date. 👍

Best thing to do would be to copy the UK voices into the ES voices folder, then say no to overwrite. Then once that is done, all the ones added should be automatically highlighted in Windows, and you can cut and paste those to a separate folder. Then you can record over them, or made new files but replace the filename, and then copy them back into the ES folder. Essentially SB is looking for those files but if they aren't present, it doesn't care - it just doesn't play a sound IIRC. Hopefully that answers the question...

OK thanks for the info. Seems we have a few more bugs to work out...