Jump to content


  • Content Count

  • Joined


About Volcano

  • Rank
    Senior Member
  • Birthday 02/14/1977

Personal Information

  • Location
  • Occupation
    Game Design

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes the devs know how it works, now granted none of us are perfect though - I have misstated some things myself from time to time (actually I did this in the Support Forum about six months ago and had to correct myself). Its a natural possibility when the software is so complicated, and continuously developed for two decades. Feature X works one way originally, then over twenty years, out of feedback, bugs fixes, or expansion, the behavior might be disconnected, or completely changed in subtle ways (with tacked on variables or conditions) into something else, many times over. That is why, very often, when a detailed question is posed in the forum then there are three bad choices for us: Don't answer, ignore the question - easiest thing to do, but is not helpful Answer the question from memory - this is quicker, but risks an incorrect answer Investigate, look it up, research, or have someone sift through code to see how it works - this is the most accurate, but most time consuming, and worst of all: spends vital time and resources that are needed for development (so its impractical) All three options are equally bad. And also, as I have seen myself first hand, when trying to not get "bogged down" in explaining precise detailed answers to very detailed questions (because it takes valuable development time to do this) then this is often met with negativity in the forum that we are ignoring the customer and the like. Then its a matter of 'why isn't it documented?'. Well, in that regard, its a question of what to document in the first place. Sure, it would be nice if everything was documented, but that isn't practical, so when it comes to documentation (for anything), its always a question of "how much?". This is where is the SB wiki comes in, which is intended to be all the 'extra documentation' that could never fit in the manual. A perfect example are the vehicle pages: some of them ARE a manual in themselves. But even with all that information, some vehicles aren't documented very well, or much at all, and some information might be missing or even no longer correct. It's just a reality, unfortunately. That said, the great thing about the SB wiki is that the community can contribute to it (I think the user has to be approved by Sean though, but if someone sends a PM then I am sure there would be no reason why they wouldn't be approved - its more to keep spambots from getting access really). So, if suppression is missing from the wiki's infantry page, then it can easily be added.
  2. SB wiki has some detailed info on infantry, including tactics and such, which may or may not be what you are looking for.
  3. Yes, unfortunately there is a bit of misinformation going on here, based on Ssnake's old memories. I suppose its natural though given that the same product has been in continuous development for 20 years. It happens. 😮 There *IS* a basic form of infantry suppression, exactly as you describe. When soldiers kneel to fire an RPG, if they are fired at then they will take cover and will be unable to fire RPG. As you say, this is suppression; firing on the enemy with an effect to pin them down and hinder them from returning fully effective fire (in this case preventing them from firing RPGs). (Whether there is an actual function in the code for suppression, or whether its simply the behavior of the non-prone soldier going prone when under fire (and then being unable to fire the RPG while prone), is a technical detail - the effect is the same, they are temporarily suppressed.)
  4. Version 1.0.0


    This is the original Paderborn map created by Manteuffel. It has been converted to a 4.1 map package with a 4.1 theme applied. The UID to download this map package: a2ec9435-93c8-4b27-b089-8b1e23d6ba8f
  5. 24 JAN scenario: Air Assault 02-4162 SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 15 (or ~12 for the FMU version) (Blue: 3, over CO + Green: 6 vs. Red: 6) NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.
  6. Well, the speed is basic mathematical calculation between mass and horsepower (power to weight ratio) and then combined with its known top speed, so its not like its rocket science. It should be an accurate representation, unless the transmission is something special that allowed it to reach 0-X kph in very short amount of time which would not be typical for its raw data. But it should be close. Also keep in mind that the tank is certainly going to be much faster in speed and acceleration on roads. But in regards to the original post... Without having seen the scenario in question, it could be that the enemy tank types might need to be downgraded. This is often true of scenarios which have the playable vehicle swapped out with a different one. We have to remember that the M60 was originally designed to fight against the T-55 and T-62 (and early T-64), where it performed well in that role versus the ammunition the Soviets had at the time. Later on with the A3 advancements, it was an attempt to prolong its life to fight against modernized T-55s, T-62s and the T-72, the latter of which could probably considered a more even match although the M60A3 would still be considered superior. M60A3 with TIS disabled, versus the T-55AM or T-72A can be fun, but tough. Then we have the TTS, a further attempt to prolong its lifespan, in which case by this time the M60 was becoming obsolete and at the limit of its capability. Its big advantage at this point was that it would dominate the Soviets during night combat and low visibility with its thermal sight, but in day time it would lose much of that superiority. The M60A3(TTS) actually has a better thermal sight than the M1 (both in real life and in Steel Beasts). Anyway, this is mostly why the M60 tank platoons had 5 tanks, and the M1 tank platoons had 4 tanks. To make a long story short, the M60 is a good tank (so is the Leo 1 and T-72), but as with anything in the 1960s-1980s this depends on the match up. If that scenario has many T-72s in it and its day time then is naturally going to be very difficult! 😮
  7. It was done to modernize the scenario. Other changes were made to Blue too (including the Blue side map updates, better missiles, better RPGs and better reinforcement vehicles). The problem of course is that Blue cannot get those reinforcement vehicles reliably, and this is where small balance changes are being made to *hopefully* make that more likely to occur. We'll see. The trick is, I don't want it too easy for Blue to gain the reinforcements, but not impossible either, so its a delicate dance that hasn't quite been nailed down just yet...
  8. IIRC, I think MERDC and solid green were used together in the late 1970s, on a unit by unit basis. Again, IIRC, by early 1980s I think most vehicles were painted in MERDC colors, but if I recall - it wasn't very uniform until the NATO 3 tone camo was adopted.
  9. 17 JAN scenario: Civil War Krasnovia-Scania-4162 SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 16 (or ~12 for the FMU version) NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules. Civil War Krasnovia-Scania-4162.zip
  10. I hope to schedule it again next month so I can get the balance nailed down. I am not looking for Blue to win, rather, just to get it where Blue has a descent shot at it. Also, apologies to my team if I was a bit testy. The scenario is easily one of the most stressful and difficult scenarios in SB; it should be used at military academies to train for stress.
  11. I suppose I could PM you a non-PW'd scenario (when I have a chance).
  12. That should not be a problem. However I do notice that the "restart.sce" file does indeed have duplicate IDs (24x on Red, 1x on Blue), likely from infantry units taking losses during a scenario, which I think can be normal behavior, but this is being investigated.
  13. Actually, I just tested both AVEPS and AFGANIT, again, and it works in this regard. T-72B1 with AVEPS, shot at the launcher and hit it three times with 25mm M919. This is not reported in the AAR, but subsequent firing of TOW missiles at the tank was ignored, and the missiles impacted the target (AVPES did not intercept - it was disabled). For T-14, T-15, etc, (AFGANIT) also worked fine. Firing 25mm at radar disabled a "sector", on the T-14 the left side defense disabled by taking out the radar on the left side of turret. The radar is the upside down trapezoidal area located on the side of the turret, in the vertical center of turret. The black rectangular box above that is NOT the radar, its the LWR. Unlike the AVEPS however, damage to the AFGANIT randar is reported in the AAR as "Light damage" (its a technical reason why AVEPS does not report damage, because its handled as an "attachment" to the vehicle, not part of the vehicle itself). No time for further explanation, sorry, but no issues observed either.
  14. There are no means to shoot out the AVEPS system's "radars", only AFGANIT systems have radars modeled - AVEPS is more like a self contained system (or at least we don't model all sorts of other attachments). AVEPS on the other hand can suffer damage to the AVEPS launcher (***IIRC***) which knocks out the entire system. If this does not work, then it could be a technical bug there, I suppose, but what you are basing this on? There are no AAR reported damages about this IIRC, it just happens, its not highly refined. That said, some vehicles don't show the AVEPS launcher, and some do, and obviously you cannot disable the AVEPS launcher if you cannot see it. That is just the way it is, when we have 200+ vehicles, and no time to add the AVEPS launcher to every single model. In this case, yes, it would be invulnerable. For AFGANIT vehicles, you cannot knock out the whole system per se, because its not a singular launcher. However, any vehicle that has AFGANIT can suffer radar damage. The radars work in "sectors" and certain AFGANIT launchers are assigned to a radar. So, damaging a radar will knock out a sector of defense, not the whole defense. Also, the radars themselves are relatively small, and are somewhat resistant to damage, and you especially aren't guaranteed to knock them out with small arms. Anyway last time I tested this it all worked some months ago and no changes were made there - so I am not aware of any bugs there.
  15. This week will be same scenario as last time -- going to give it one more chance before we skip it (last week we ended up playing something else instead). 10 JAN scenario: Island Invasion 02-4162a (updated/enhanced with new 4.1 vehicles and features, 2020 era) SPECIAL CONSIDERATIONS: Draft? Yes. Random CO selection? Yes. Minimum # players: 10 or 12 (10 for the FMU version) NOTES: Remember to play within the TGIF House Rules and SB.com Community Rules.
  • Create New...