Russian-Afghan War 1

[Scully]

All,

I've posted my first scenario design ever, for any game. It's at the link below.

This is a small scenario that has a Russian Motor Rifle Company clearing the objective of all Mujahideen units to ensure a convoy is not attacked.

http://www.wargames.warfarehq.com/forums/showthread.php?t=413

Map Files (Download both):
http://www.wargames.warfarehq.com/forums/showthread.php?t=336
http://www.wargames.warfarehq.com/forums/showthread.php?t=335

Database files:
http://www.wargames.warfarehq.com/forums/showthread.php?t=414

Please pass along your comments so I can improve for the next scenario, which will probably be another Russian-Afghan affair.

Thanks for downloading and I hope you enjoy my first scenario.

Take care,
Brian

[KG_Norad]

Can't wait to give it a try! :D

[Pat Proctor]

:ar15:

Sweeeeeeeeet!

[Deltapooh]

Cool. Gonna have to give this one a go.

Your hard work is appreciated.

[Scully]

Thanks for the support guys. I only hope the scenario lives up to your comments. I didn't realize it would be so nerve racking putting a scenario out there...but it is.

Take care,
Brian

[Ivan Rapkinov]

Scully:

niiiiice :)

Most of my losses came about because I hasn't exactly sure how the mujahedeen would have set themselves up - I probably "moved to contact" a little too aggressively, and then my dismounts were not too effective.

A suggestion would be to change the name of the DPL team to something more USish - just so at a glance you know where they're going...and what they can do, without having to go through the info menu.

those PKMs are nasty...

[Alkiviadis]

I can't get it to load either in the main program or the editor, just kicks right out the executable. I patch to date, running at 16 bits color. Suggestions?

[Scully]

I can't get it to load either in the main program or the editor, just kicks right out the executable. I patch to date, running at 16 bits color. Suggestions?

Hey Alkiviadis,

Thanks for downloading the scenario. I'm not sure what the problem could be, so I apologize for asking this, but did you download all the files (scenario, database, and map) and are they all in the right folder (They should be in the "data" folder)?

Anyone else have thoughts on this?

Thanks,
Brian

[kbluck]

I can't get it to load either in the main program or the editor, just kicks right out the executable.

ATF crashing to desktop with no useful error message while loading a scenario is standard behavior when you don't have the right map files. Something similar may happen when you don't have the right database files. In short, you're missing something needed for the scenario.

This is, of course, a bug; it should instead pop a message box saying, "Hey, you don't have the right map!" or something similar. This is one of the headaches for scenario designers; ATF is very brittle about loading files, and given the lack of organization in the data files it is extremely easy to misplace stuff or corrupt files with mismatched versions, which then causes the game to fail catastrophically with little indication of what is wrong.

--- Kevin

[kbluck]

Scully: in line with this general issue, it is very helpful to your downloaders when you provide clickable links to all the various pieces that need to be downloaded. At the moment your scenario download post pretty much leaves it up to the customer to figure out where to find the map and the database.

Sometimes it makes sense to include everything in the scenario zip, but only if you are providing scenario-specific database files; always better not to overwrite existing ones. I myself have had mixed success with this. And, of course, maps are sometimes too big to upload here.

--- Kevin

[Scully]

Scully: in line with this general issue, it is very helpful to your downloaders when you provide clickable links to all the various pieces that need to be downloaded. At the moment your scenario download post pretty much leaves it up to the customer to figure out where to find the map and the database.
--- Kevin

Good point. I'll add those to the thread.

Thanks,
Brian

[Scully]

Here are the additional links for the scenario. I've also added them into the original post. Sorry for any trouble this has caused. Brian

Maps (download both):
http://www.wargames.warfarehq.com/forums/showthread.php?t=336
http://www.wargames.warfarehq.com/forums/showthread.php?t=335

Database:
http://www.wargames.warfarehq.com/forums/showthread.php?t=414

[CPangracs]

You say it is "based" on the kbmodern db, but you don't specify that you MUST have that database to play! You should either rename each file in the database to match your database name and include it in your download, or make sure it is absolutely clear that anyone who wants to play your scenario MUST have that database to play it.

[Scully]

You say it is "based" on the kbmodern db, but you don't specify that you MUST have that database to play! You should either rename each file in the database to match your database name and include it in your download, or make sure it is absolutely clear that anyone who wants to play your scenario MUST have that database to play it.

Thanks for catching that Curt. I thought all the components were included in what I uploaded. I'll fix that tonight and re-upload.

Brian

[kbluck]

Interesting little scenario. Nice to play something other than post-2000 US forces for a change. File deployment issues aside, it all seems to work pretty well.

A few notes for your consideration:

The scenario and database files extract by default into subfolders. This means ATF can't find them until they're moved back into the Data folder. Better not to put subfolder paths into the ZIP file. It may be possible to put *most* files into subfolders (although my experiments with this have had spotty success) but certain "top-level" files *must* be in Data for the game to find them; the *.dbs file, for example. In general, its too much heartburn at this point in the game's development to do so; safest to just dump everything into Data for now.

As Curt mentioned, if you leave references to another database in your *.dbs, you are effectively making your scenario dependent on that DB as well. You might want to copy the *.pca and *.smg as well, even if you aren't changing them, just to make it all self-contained.

DP: You asked about the map color. On my computer at least, the "Rocky" hue is a hideous, headache-inducing burnt-orange. It looks like the terrain is coated with caramel. Icky. I'd stick with Desert.

OPORD: Not wrapping, I suspect because the viewer automatically loads Notepad to view the .txt file and I happen to have "Word Wrap" turned off in mine. Simply renaming it to *.htm should solve that, even if the contents aren't really HTML.

TOE Note: Typical Russian APC company includes 11 BTRs; three per platoon, one HQ and one ATGM section. Believe it or not, they don't have any organic PKMs. Of course, it is not unreasonable in this case to expect them to have "augmented" themselves somehow with the MGs and left the ATGMs behind.

I think the mujahidin are a bit too visible, given their renowned abilities at camouflage and the Soviet's generally poor imaging capabilities at the time. Might need to shrink the "dimensions" in the DBs even further. I would set as small as necessary so teams in defilade and hold fire can't be seen at all by normal units until well within their fire envelopes, perhaps a couple hundred meters. To take advantage of this, I'd pack 3-6 teams into "platoons" located close together, maybe 30 meters between teams, and set them on hold fire. Then draw an event ellipse around them at the approximate range you want them to open fire and cancel toggle. Alternatively, you could simply set up a max range fire control SOP, but actually I've had some trouble making that work.

The pullback works well, but with the event box method they tend to pull off before they really engage anything. I'd make the pullback casualty-based, i.e. they pull out when the unit count for the "battalion" drops below a certain number. Callback count will do that for you. After all, there's no reason to pull back if you're kicking the enemy's ass.

Suggestion for victory conditions: requiring the extermination of every last guy with an AK is a bit grueling. Six hours is a long game, and most of it consists of fairly unexciting snooping around in the rocks looking for isolated enemy teams that would present no real threat to the defile. Perhaps you could set up a convoy of trucks as an "allied" force, due to arrive at a certain time hack, and make the victory dependent on them getting completely down their path with no casualties?

Engine problems: The dismounting chaos really screws things up. It takes a half-hour just to collect up the dismounts once they leave their BTRs. If, as is fairly likely, you dismount close to the enemy, dismounts often end up *behind* the enemy, and almost without fail too far apart to offer mutual support initially. Also, it would be very nice to have the mujahidin set to suppress anything in range, especially the heavy weapons, but the game's suppress radius mechanism makes that impossible as a practical matter. And, of course, direct fire suppression really isn't effective anyway, no matter how overwhelming, due to the "flicker" effect allowing the suppressed enemy to fire back without any real impediment. Honestly, I don't think dismount-intensive scenarios are going to be really satisfying until these engine-level issues are dealt with somehow.

Hope this is helpful to you.

--- Kevin

[Scully]

Kbluck,

Thanks for your comments. Very helpful.

The scenario and database files extract by default into subfolders. This means ATF can't find them until they're moved back into the Data folder. Better not to put subfolder paths into the ZIP file. It may be possible to put *most* files into subfolders (although my experiments with this have had spotty success) but certain "top-level" files *must* be in Data for the game to find them; the *.dbs file, for example. In general, its too much heartburn at this point in the game's development to do so; safest to just dump everything into Data for now.

As Curt mentioned, if you leave references to another database in your *.dbs, you are effectively making your scenario dependent on that DB as well. You might want to copy the *.pca and *.smg as well, even if you aren't changing them, just to make it all self-contained.

You and Curt are right on the file issue. I'll work to fix that tonight and make sure it doesn't happen in future scenarios. I certainly understand the talk about needing a better file management system in ATF. :)

Quick question on the file paths...how can I change that to make sure it's not steering towards an incorrect subfolder? I didn't purposefully link it to a subfolder...I'll have to take a look at that as well tonight.


OPORD: Not wrapping, I suspect because the viewer automatically loads Notepad to view the .txt file and I happen to have "Word Wrap" turned off in mine. Simply renaming it to *.htm should solve that, even if the contents aren't really HTML.
I didn't realize that would work. I'll give that a try tonight as well.

TOE Note: Typical Russian APC company includes 11 BTRs; three per platoon, one HQ and one ATGM section. Believe it or not, they don't have any organic PKMs. Of course, it is not unreasonable in this case to expect them to have "augmented" themselves somehow with the MGs and left the ATGMs behind.

According to my sources, the PKMs were organic in Afghanistan. You are also correct on the ATGM's, but I took them out because the actual combat I based the scenario on (based is probably a little strong) did not have ATGM's. Though I agree that they are normally standard in a MRC.


I think the mujahidin are a bit too visible, given their renowned abilities at camouflage and the Soviet's generally poor imaging capabilities at the time. Might need to shrink the "dimensions" in the DBs even further. I would set as small as necessary so teams in defilade and hold fire can't be seen at all by normal units until well within their fire envelopes, perhaps a couple hundred meters. To take advantage of this, I'd pack 3-6 teams into "platoons" located close together, maybe 30 meters between teams, and set them on hold fire. Then draw an event ellipse around them at the approximate range you want them to open fire and cancel toggle. Alternatively, you could simply set up a max range fire control SOP, but actually I've had some trouble making that work.

Good idea.

The pullback works well, but with the event box method they tend to pull off before they really engage anything. I'd make the pullback casualty-based, i.e. they pull out when the unit count for the "battalion" drops below a certain number. Callback count will do that for you. After all, there's no reason to pull back if you're kicking the enemy's ass.

I was initially planning on doing it that way (I actually asked a couple of questions about it at some point). However, I thought it was more likely that the Russians would try to move around the flanks and cut the mujahideen's retreat route off. I figured that if the mujahideen knew the Russians were coming to their flank they'd want to pull back to their secondary locations.

Suggestion for victory conditions: requiring the extermination of every last guy with an AK is a bit grueling. Six hours is a long game, and most of it consists of fairly unexciting snooping around in the rocks looking for isolated enemy teams that would present no real threat to the defile. Perhaps you could set up a convoy of trucks as an "allied" force, due to arrive at a certain time hack, and make the victory dependent on them getting completely down their path with no casualties?

Another good idea.

Honestly, I don't think dismount-intensive scenarios are going to be really satisfying until these engine-level issues are dealt with somehow.

That was actually one of my biggest concerns with the scenario. I actually had my eye on doing a major Russian sweep of a valley with the addition of air assault troops and obviously more Russian and Mujahideen units. This one is documented fairly well in one of the books I have (I think bear went over the mountain). Is there a better way to handle dismounts under the current engine that might make such a scenario more enjoyable?

Thanks again for all your comments. I appreciate your help.

Brian

[kbluck]

"Quick question on the file paths...how can I change that to make sure it's not steering towards an incorrect subfolder?"

If you use WinZip, I think it usually happens when you drag a folder into the archive rather than selecting all the files.


Is there a better way to handle dismounts under the current engine that might make such a scenario more enjoyable?

There's not much you can do about dismounting scatter. It'll have to be fixed in code, if Pat agrees that it is a problem.

I'm not sure what the deal is with direct-fire suppression. I suspect suppression duration has some relationship to pK. It may well be that by reducing pKs for dismounts against most weapons to single-digit values, it also vastly cut the suppression times as well, in most cases to apparently sub-second duration. Pat would need to verify that suspicion. I seem to recall that back in v.1.02, it didn't "flicker" so much; rather, suppression levels "built up" as bursts accumulated on a target, which I found quite pleasing at the time. I believe the "flicker" effect started with 1.03. I couldn't say why.

At any rate, I do think that calculation needs to be revisited in the next patch/release; perhaps duration of suppression should be a formula involving mainly Suppress Radius vs. Protection Level, since it can be assumed that weapons with large radii have greater suppressive effects in general. I think suppression is generally more related to sheer volume of fire, not necessarily effectiveness of that fire. It is not unheard of for armored forces to be turned back by vigorous resistance, even though the defenders have no actual anti-armor weapons and no real hope of killing anything.

I'm also not clear on whether direct-fire weapons have suppressive effects on everything in the weapon's radius, or merely on the target. I suspect the latter.

The Suppress SOP circle issue I think is simply a logical-seeming idea that doesn't work out well in practice. While it is true that a given unit could effectively suppress only a limited area, this is sort of "self-regulating", since if you try to suppress an entire company using a single squad, the company won't be very well suppressed regardless of arbitrary control measures like the circle. If you want the squad to concentrate on a particlar subset of the company, it may have more success, but why not use the existing Fire Control SOPs for that purpose?

Meanwhile, the radius is a pain for the human player to constantly update, since units won't shoot outside of it under any circumstances, and it makes it almost impossible for scenario editors to program their forces to use suppressive fire, since the human player rarely does exactly what you expect. I think units on Suppress SOP should simply try to suppress everything within range, target selection weighted by range and pK, while respecting Fire Control. I also think it should be possible to kill targets you're suppressing, even if they're only "yellow-spotted", although of course the pH should be considerably lower than with a good spot.

Again, this is something that has to be dealt with in code, if Pat agrees it is a problem.

--- Kevin

[Scully]

I added the additional components to the database as recommended. It can be downloaded at the same location as the previous one -- http://www.wargames.warfarehq.com/f...hread.php?t=414.

Thanks,
Brian