MajorH
Member
TacOps Gazette 04.01
> This [suggestion] shouldn't be difficult to do.
Nothing seems difficult to you gents.
I on the other hand have to work within the framework of the existing body of code which consists of 383,000 lines for TacOps v4 , 408,000 lines for TacOps v5, and 204,000 lines for the current map tool.
> Why do so many small units, even trucks, have RPGs and LAWs?
In contemporary combat one can not reasonably predict who on the battlefield might have a low tech or disposable antiarmor weapon. Many wargames treat ordinary dismounted infantry as merely speed bumps vs armor which is very untrue in real life. I found that giving at least one disposable RPG/LAAW to almost every unit type (even trucks) in the game handled this issue very simply.
> I was wondering how you decided
> to load some of the infantry teams as you did.
The ammo load for small arms and crew served weapons is abstracted to be slightly heavy. I took the normal combat load that each person carries for his weapon and I then added more for the extra ammo that is typically a shared load spread across a squad and or that is normally located fairly close to units in contact. For example, a machine gunner does not usually hump more than one belt or drum for his weapon. If he did then he could not have his weapon at the ready for instant employment. The rest of the machine gun ammo is a shared load of the team or squad. Ammo for the M203s is handled similarly. A dismounted unit located anywhere near an APC would have access to even more ammo. More ammo would also be floating around in the hands of numerous two to four man teams of ammo bearers (that are not represented in TacOps) that would usually be constantly moving ammo up to units in contact. The later item plus prestaged ammo is also the basis of the instant resupply abstraction.
By simply overloading dismounted units I saved several bytes of memory use for every unit in play, avoided thousands of calculations per minute of game play, avoided inflicting more trivial detail work and mouse clicks on the player, and avoided thousands of lines of complicated logistics tracking code that would have in the end produced almost exactly the same game play results as the simple overloading solution.
> I am also curious about some of the soft vehicles, like
> trucks, carrying a couple of AT-4's.
Supply trucks move around a lot without escort. In a general war situation drivers tend to accumulate personal stashes of small arms ammo including grenades and disposable rocket launchers.
> Doesn't this entice players to go tank-hunting with a
> deuce-and-a-half?
That would be an unrealistic/gamey employment of trucks but I don't see a reasonable way to prevent it.
> Will we be seeing any new units such as terrorists, suicide
> bombers, etc?
They have been in the TacOps4 unit data base since 2002. Portable and transportable bombs and a variety of "civilian" and irregular forces unit markers were added to v4 as part of the U.S. Army contract for TacOpsCav. They are already included in the retail v4.
> I tried to add bombs [portable bomb and transportable bomb]
> to a scenario tonight, but they kept blowing up on the first
> turn, even though I had the time values set for greater lengths.
The numbers that you enter into the bomb timer are not "lengths" they are the hour and minute parts of a clock time. In other words, you enter numbers that indicate at what clock time the bomb is to go off. Example ... say the current time in the game is 0800 and you want the bomb to go off in 15 minutes, which will be a game clock time of 0815. Then you would enter 08 and 15 in the bomb timer window.
> Do you plan to implement CAP type air patrols?
I have no plans to implement fixed wing aircraft vs fixed wing aircraft combat in TacOps. If an incoming air strike had not been intercepted well before it reached the air space over a typical TacOps sized map then it would probably be too late to do so anyway. If you want to simulate that one side has air superiority then just don't give any air strikes to the other side.
> I would like to be able to have a flight loiter a bit above the
> battlefield.
Ground attack aircraft do not loiter over a tactical battlefield unless there is absolutely no SAM or AAA threat. They usually loiter several minutes away from the tactical battlefield. A jet aircraft can cover a lot of ground in one or two minutes.
> I would like to be able to mass set firing ranges for
> all units or all units of a particular type (e.g. the ability to set all my
> M1A1's to 2000 meters in one button click). Copying and pasting
> ranges would be nice too.
Select a group of unit markers by dragging out a selection rectangle and or by "shift + click" on each desired marker. Then select the "Orders/Set Engagement Range" menu item. Enter the desired range and close the window. The range setting will be applied to only the selected markers.
> Being able to mass set SOPs by unit type would be
> nice also.
Adroit use of the Copy SOP feature, the Paste SOP feature, plus the group marker selection features will accomplish just about the same thing.
> How are the logistics packs counted towards the load
> capacity of a vehicle?
If I explained it accurately, you would just say "What?". Log packs are highly abstract and so are the program routines that handle them. The program enforces an unscientific, fuzzy logic limit (TRANSLATION - a 2:00 am Jim Beam inspiration) whose main purpose is to prevent blowing some program cargo routines that were not originally intended to be used for this task. Basically, larger vehicles can carry more log packs than smaller ones. Other than that you will just have to experiment.
> If a unit is spotted by a helicopter or UAV, or I guess any
> friendly unit, does that raise the chance that it will be spotted
> by all other friendly units as well?
Yes. An enemy unit that is spotted by one friendly unit is spotted by all friendly units of the same color. However, that does not mean that every friendly unit that is capable of shooting at that enemy unit will choose to do so. Spotting is very transient and is linked as much to target activity as it is to visibility and line of sight (assuming a clear line of sight). In other words spotting can often be lost if a target unit stops moving and shooting. That is why firefights sometimes seem to fade away even though all the participating units are in the same stationary positions and then ramp up again when somebody moves.
>If I have a counter with 4 tanks, that counter makes one
> spotting check for all four tanks, correct?
Yes and no. There is a gross spotting check that only happens once per friendly marker per 15 second pulse. This check has no random factors so there is no reason to repeat it for each strength point in the marker. If the gross spotting check reveals an enemy unit then there is a targeting or acquisition check that is done by each strength point in the marker.
>And if one tank fires at a target, that counts towards raising
> the chance of a hit for the remaining 3 tanks in the counter,
> correct?
Yes but not until the next 15 second pulse.
>Can TacOps handle 1000 units each BLUE and RED?
Yes. Games have been played with 1000 to 2000 markers in play. There is no hard coded limit on the number of unit markers that can be in play. However, at some point an extreme number of unit markers would exhaust memory or could be expected to cause game variables to malfunction.
> I have four colors with together some more than 10,000 units.
> In order to speed up network traffic I tried to delete about
> 1300 of them in one step. Since then my TacOps hangs
> (5 minutes or so). Is this explainable?
The program was probably not hung or crashed - it was probably just still processing the deletions. It takes a bit of time to delete a unit. The memory occupied by that unit record must be released (trivial) and the record for every other unit in play must be checked (not trivial) to see if it knows something about the deleted unit, has some sort of relationship to that unit, or has a pending order that involves that unit. Do that for an exaggerated number of units (such as 1300) via a group selection and the time becomes significant. I just did an experiment on a Mac G4 tower. It took 2 minutes and 17 seconds to delete 1300 group selected unit markers. It took 3 minutes and 15 seconds to delete 2000.
> I am looking to change my PC for Apple Mac and wonder if my
> TacOps4 CD is compatible.
Both versions of TacOps are on your CD. The TacOps4 CD has always been a hybrid CD that contains both a Windows and a Macintosh version of the TacOps game package. If you place the CD in a Windows computer you will be shown only the Windows version (actually a Windows installer package). If you place the CD in a Macintosh computer then you will be shown only the Macintosh package. However, TacOps4 is not compatible with the Macintosh OSX operating system. You must run TacOps4 on the Macintosh in OS9 native mode or in OS9 Classic mode (which used to be part of OSX but may not be anymore). It is possible that the new Macs that are currently on sale do not offer OS9 or OS9 Classic modes anymore. The Military reference library has no conflict with Mac OSX since it only contains Adobe Reader PDF files.
> I would like to have floating palettes that are always present for
> common user interface functions.
I prefer to devote every bit of screen possible to unobstructed map display. That means no decorative borders, no borders filled with short cut buttons, and no permanent floating palettes. Floating palettes obstruct the player's view of the map and the unit markers on it. They complicate the ability of the program to track what it is that the user is really doing at the instant which is very important in order to not present choices to the user that are confusing or inappropriate for the current program state. They complicate and slow the program interface and network event sensing and response processes. I can't afford much complexity or sluggishness in event sensing and processing when there could potentially be 30 to 50 work stations in a military multiplayer game session.
> Why are there letters in the TacOps version number?
The traditional version number convention of "x.y.z" doesn't lend itself to the way that I simultaneously maintain and enhance the retail and the several military versions of TacOps, especially when I am testing one of the versions. So several years ago I began using two additional characters in the TacOps version string. Instead of frequently incrementing the "x.y.z" part of the version string, I usually just increment the two characters at the end. AA leads to AB which leads to AC, etc. Once the second character gets to Z then I increment the first character and start over with A in the second character. AZ leads to BA, etc.
> Why do I have to change to 256 colors to get some user made
> maps to open in TacOps?
If the total size of a map (width in pixels x height in pixels) is greater than 8,355,839 pixels then the map can not usually be loaded on obsolete versions of Windows if monitor colors are set at greater than 256 colors. The exact Windows call that is failing at higher color settings is CreateCompatibleBitmap(...). This is due to a bug in the Windows OS that was not fixed until Windows XP. If you want to avoid this issue, move to Windows XP.
> I don't think either of us are zipping our PBEM orders, though I'm
> not certain what Apple's Mail program does with multiple
> attachments. I simply drop the two orders files on a new message
> and send them.
If PBEM orders files are not zipped then you have no protection from Internet mysteries corrupting the orders file. It seldom happens but when it does the game goes awry. However, usually when this happens the result is far more noticeable than what you encountered. Unzipped orders files can also be corrupted by various "helpful" things that some email programs try to do to attachments based on preference settings. Even zipped orders files can be damaged, especially on Macs, if the email program has a preference setting to automatically unzip and or open a zipped attachment and or if the associated unzip/unstuff program has its preferences set to something like "convert text to Mac format".
> Why are there no cargo trailers in TacOps. I
> know that they don't shoot but they would add realism to OOB's.
The number of trailers in an Army battalion is staggering. I don't see much advantage to adding so many markers and so much new work for the player when the capacity that they provide can be abstracted simply by allowing cargo vehicles to be somewhat overloaded.
> This [suggestion] shouldn't be difficult to do.
Nothing seems difficult to you gents.
I on the other hand have to work within the framework of the existing body of code which consists of 383,000 lines for TacOps v4 , 408,000 lines for TacOps v5, and 204,000 lines for the current map tool.> Why do so many small units, even trucks, have RPGs and LAWs?
In contemporary combat one can not reasonably predict who on the battlefield might have a low tech or disposable antiarmor weapon. Many wargames treat ordinary dismounted infantry as merely speed bumps vs armor which is very untrue in real life. I found that giving at least one disposable RPG/LAAW to almost every unit type (even trucks) in the game handled this issue very simply.
> I was wondering how you decided
> to load some of the infantry teams as you did.
The ammo load for small arms and crew served weapons is abstracted to be slightly heavy. I took the normal combat load that each person carries for his weapon and I then added more for the extra ammo that is typically a shared load spread across a squad and or that is normally located fairly close to units in contact. For example, a machine gunner does not usually hump more than one belt or drum for his weapon. If he did then he could not have his weapon at the ready for instant employment. The rest of the machine gun ammo is a shared load of the team or squad. Ammo for the M203s is handled similarly. A dismounted unit located anywhere near an APC would have access to even more ammo. More ammo would also be floating around in the hands of numerous two to four man teams of ammo bearers (that are not represented in TacOps) that would usually be constantly moving ammo up to units in contact. The later item plus prestaged ammo is also the basis of the instant resupply abstraction.
By simply overloading dismounted units I saved several bytes of memory use for every unit in play, avoided thousands of calculations per minute of game play, avoided inflicting more trivial detail work and mouse clicks on the player, and avoided thousands of lines of complicated logistics tracking code that would have in the end produced almost exactly the same game play results as the simple overloading solution.
> I am also curious about some of the soft vehicles, like
> trucks, carrying a couple of AT-4's.
Supply trucks move around a lot without escort. In a general war situation drivers tend to accumulate personal stashes of small arms ammo including grenades and disposable rocket launchers.
> Doesn't this entice players to go tank-hunting with a
> deuce-and-a-half?
That would be an unrealistic/gamey employment of trucks but I don't see a reasonable way to prevent it.
> Will we be seeing any new units such as terrorists, suicide
> bombers, etc?
They have been in the TacOps4 unit data base since 2002. Portable and transportable bombs and a variety of "civilian" and irregular forces unit markers were added to v4 as part of the U.S. Army contract for TacOpsCav. They are already included in the retail v4.
> I tried to add bombs [portable bomb and transportable bomb]
> to a scenario tonight, but they kept blowing up on the first
> turn, even though I had the time values set for greater lengths.
The numbers that you enter into the bomb timer are not "lengths" they are the hour and minute parts of a clock time. In other words, you enter numbers that indicate at what clock time the bomb is to go off. Example ... say the current time in the game is 0800 and you want the bomb to go off in 15 minutes, which will be a game clock time of 0815. Then you would enter 08 and 15 in the bomb timer window.
> Do you plan to implement CAP type air patrols?
I have no plans to implement fixed wing aircraft vs fixed wing aircraft combat in TacOps. If an incoming air strike had not been intercepted well before it reached the air space over a typical TacOps sized map then it would probably be too late to do so anyway. If you want to simulate that one side has air superiority then just don't give any air strikes to the other side.
> I would like to be able to have a flight loiter a bit above the
> battlefield.
Ground attack aircraft do not loiter over a tactical battlefield unless there is absolutely no SAM or AAA threat. They usually loiter several minutes away from the tactical battlefield. A jet aircraft can cover a lot of ground in one or two minutes.
> I would like to be able to mass set firing ranges for
> all units or all units of a particular type (e.g. the ability to set all my
> M1A1's to 2000 meters in one button click). Copying and pasting
> ranges would be nice too.
Select a group of unit markers by dragging out a selection rectangle and or by "shift + click" on each desired marker. Then select the "Orders/Set Engagement Range" menu item. Enter the desired range and close the window. The range setting will be applied to only the selected markers.
> Being able to mass set SOPs by unit type would be
> nice also.
Adroit use of the Copy SOP feature, the Paste SOP feature, plus the group marker selection features will accomplish just about the same thing.
> How are the logistics packs counted towards the load
> capacity of a vehicle?
If I explained it accurately, you would just say "What?".
Log packs are highly abstract and so are the program routines that handle them. The program enforces an unscientific, fuzzy logic limit (TRANSLATION - a 2:00 am Jim Beam inspiration) whose main purpose is to prevent blowing some program cargo routines that were not originally intended to be used for this task. Basically, larger vehicles can carry more log packs than smaller ones. Other than that you will just have to experiment. > If a unit is spotted by a helicopter or UAV, or I guess any
> friendly unit, does that raise the chance that it will be spotted
> by all other friendly units as well?
Yes. An enemy unit that is spotted by one friendly unit is spotted by all friendly units of the same color. However, that does not mean that every friendly unit that is capable of shooting at that enemy unit will choose to do so. Spotting is very transient and is linked as much to target activity as it is to visibility and line of sight (assuming a clear line of sight). In other words spotting can often be lost if a target unit stops moving and shooting. That is why firefights sometimes seem to fade away even though all the participating units are in the same stationary positions and then ramp up again when somebody moves.
>If I have a counter with 4 tanks, that counter makes one
> spotting check for all four tanks, correct?
Yes and no. There is a gross spotting check that only happens once per friendly marker per 15 second pulse. This check has no random factors so there is no reason to repeat it for each strength point in the marker. If the gross spotting check reveals an enemy unit then there is a targeting or acquisition check that is done by each strength point in the marker.
>And if one tank fires at a target, that counts towards raising
> the chance of a hit for the remaining 3 tanks in the counter,
> correct?
Yes but not until the next 15 second pulse.
>Can TacOps handle 1000 units each BLUE and RED?
Yes. Games have been played with 1000 to 2000 markers in play. There is no hard coded limit on the number of unit markers that can be in play. However, at some point an extreme number of unit markers would exhaust memory or could be expected to cause game variables to malfunction.
> I have four colors with together some more than 10,000 units.
> In order to speed up network traffic I tried to delete about
> 1300 of them in one step. Since then my TacOps hangs
> (5 minutes or so). Is this explainable?
The program was probably not hung or crashed - it was probably just still processing the deletions. It takes a bit of time to delete a unit. The memory occupied by that unit record must be released (trivial) and the record for every other unit in play must be checked (not trivial) to see if it knows something about the deleted unit, has some sort of relationship to that unit, or has a pending order that involves that unit. Do that for an exaggerated number of units (such as 1300) via a group selection and the time becomes significant. I just did an experiment on a Mac G4 tower. It took 2 minutes and 17 seconds to delete 1300 group selected unit markers. It took 3 minutes and 15 seconds to delete 2000.
> I am looking to change my PC for Apple Mac and wonder if my
> TacOps4 CD is compatible.
Both versions of TacOps are on your CD. The TacOps4 CD has always been a hybrid CD that contains both a Windows and a Macintosh version of the TacOps game package. If you place the CD in a Windows computer you will be shown only the Windows version (actually a Windows installer package). If you place the CD in a Macintosh computer then you will be shown only the Macintosh package. However, TacOps4 is not compatible with the Macintosh OSX operating system. You must run TacOps4 on the Macintosh in OS9 native mode or in OS9 Classic mode (which used to be part of OSX but may not be anymore). It is possible that the new Macs that are currently on sale do not offer OS9 or OS9 Classic modes anymore. The Military reference library has no conflict with Mac OSX since it only contains Adobe Reader PDF files.
> I would like to have floating palettes that are always present for
> common user interface functions.
I prefer to devote every bit of screen possible to unobstructed map display. That means no decorative borders, no borders filled with short cut buttons, and no permanent floating palettes. Floating palettes obstruct the player's view of the map and the unit markers on it. They complicate the ability of the program to track what it is that the user is really doing at the instant which is very important in order to not present choices to the user that are confusing or inappropriate for the current program state. They complicate and slow the program interface and network event sensing and response processes. I can't afford much complexity or sluggishness in event sensing and processing when there could potentially be 30 to 50 work stations in a military multiplayer game session.
> Why are there letters in the TacOps version number?
The traditional version number convention of "x.y.z" doesn't lend itself to the way that I simultaneously maintain and enhance the retail and the several military versions of TacOps, especially when I am testing one of the versions. So several years ago I began using two additional characters in the TacOps version string. Instead of frequently incrementing the "x.y.z" part of the version string, I usually just increment the two characters at the end. AA leads to AB which leads to AC, etc. Once the second character gets to Z then I increment the first character and start over with A in the second character. AZ leads to BA, etc.
> Why do I have to change to 256 colors to get some user made
> maps to open in TacOps?
If the total size of a map (width in pixels x height in pixels) is greater than 8,355,839 pixels then the map can not usually be loaded on obsolete versions of Windows if monitor colors are set at greater than 256 colors. The exact Windows call that is failing at higher color settings is CreateCompatibleBitmap(...). This is due to a bug in the Windows OS that was not fixed until Windows XP. If you want to avoid this issue, move to Windows XP.
> I don't think either of us are zipping our PBEM orders, though I'm
> not certain what Apple's Mail program does with multiple
> attachments. I simply drop the two orders files on a new message
> and send them.
If PBEM orders files are not zipped then you have no protection from Internet mysteries corrupting the orders file. It seldom happens but when it does the game goes awry. However, usually when this happens the result is far more noticeable than what you encountered. Unzipped orders files can also be corrupted by various "helpful" things that some email programs try to do to attachments based on preference settings. Even zipped orders files can be damaged, especially on Macs, if the email program has a preference setting to automatically unzip and or open a zipped attachment and or if the associated unzip/unstuff program has its preferences set to something like "convert text to Mac format".
> Why are there no cargo trailers in TacOps. I
> know that they don't shoot but they would add realism to OOB's.
The number of trailers in an Army battalion is staggering. I don't see much advantage to adding so many markers and so much new work for the player when the capacity that they provide can be abstracted simply by allowing cargo vehicles to be somewhat overloaded.
