MajorH TacOps Developer Posted October 27, 2002 Share Posted October 27, 2002 TacOps Gazette 02.02 >Will there be a network CPX this weekend? One of these days, I am going to start a crusade to liberate adults from weekday phobia. With some exceptions, we do not have Mom saying "Its a school night" anymore. What would be a good scientific sounding name for "fear or guilt about recreation on a weekday night"? >Can the umpire in a multiplayer game give orders to units? Yes. Give them PIN 0, and they then belong to the umpire. Actually, the umpire can give orders (that will be carried out) to any unit with any PIN (and arty and air support) so long as there is no player currently on the network who has that same PIN. If there is a player on the network with the same PIN then that player's orders will overwrite those of the umpire at the next orders exchange. >This goes back to what I consider the most important lesson to >come out of CPX San Splendido, the need for adequate time for >planning. When I run "Return to San Splendido" in October, (to >accommodate Ralf's vacation plans) I am planning on sending out >the game materials two weeks before the game so that the players >have time to meet, either via IRC or email and plan and sent the >exported OOB file around to get the forces deployed. Time to plan >makes game day much easier for everybody concerned. It would be equally valid to have an exercise where no more than an hour was allowed for pregame coordination. Could call this a "FRAGO" style exercise. When the players first assemble online they have no choices with regard to the initial tactical disposition nor organization of their unit markers. They get a simple frag order and one hour to cross the line of departure. The only thing they get before game day is a warning order and a map graphic (for informational use only) showing their units plus known/estimated enemy positions. >From an umpire's view, this is probably one of the most important >things to come out of 4.0. It moves the burden of unit deployment >and assignment of PINs from the Umpire to the players leaving the >umpire more time to deal with the myriad of other details that crop >up during a game. Interesting interpretation and reasonably valid for recreational gaming but one of the first lessons to come out of the early Army testing at Fort Knox was just the opposite. Their request was to move as much pregame setup work as possible from the players to the umpire. The Army wanted minimal student exposure to game mechanics so that their focus would remain on tactics and communications. "Gamey" details were transferred to the umpire. The students are busy. They don't have time to do pregame setup activities. The umpire is generally the most skilled TacOps user. He can do setup activities faster and with less chance of error than the students. In prolonged offensive operations in the real world, commanders seldom have the luxury of perfectly organizing their units for a set piece battle. More often their units are where they are because of earlier operations and events. They must continue operations based on where they are and not on where they wished they were. Repositioning and reorganizing units for the impending operations is part of the exercise but it is done during game play via orders and movement and not as a pregame setup activity. >Is it planned or even now possible for the umpire to change the > amount of ammo a vehicle has on board? It is on the wish list but it has no priority. >Does map size affect orders exchange time? No. >Can you advise why the chat utility within TacOps is seldom used in >TacOps multi-player CPX's. The chat feature in TacOps is far less capable than the numerous available IRC chat clients that have been designed specifically to support group chats with lots of bells and whistles. >When combat is forced by the umpire computer, can you send a >message "last orders" for like 2 or 5 seconds and afterwards change >to combat mode? Noted as a possible future option. I can not make this an "all the time" feature because many users (particularly the military users) do not want anything hard wired into the program that would slow the progress of a game session - not even by only a few seconds per turn. In general these users want faster game play than is currently possible and actually want fewer options because they don't want to have to do very much training with the users on game mechanics. >In a multiplayer network game, after the combat phase is over, >it takes a while for the menus to become available again. >The unit markers, however, are available earlier. >Is that correct? Yes. The combat phase can finish on one computer in a network game much sooner than it finishes on another due to (a) a mix of newer vs older computers on the network and ( the use by one or more players of the "click sound' instead of full battle sounds. It is important that the game engine not allow a player to start messing with his unit markers until the combat phase has finished on every computer on the network. >Hmm, is it possible to change PINs if I am umpire/host in a two >player network game? The umpire can change PINs on the fly in a multiplayer game but not in a two player game. In a two player network game, the program needs Blue to always be PIN 1 and Red to always be PIN 2. >So I will have to host a pseudo multiplayer game, import the OOB, >change the PINs to 2, export the OOB, host a two player game, >import the OOB... and the same for BLUE, too, of course. You are on the right track here but using the import/export feature is inefficient for the goal of converting a multiplayer game to a two player game. It would be much faster to use the PIN setting items in the Network Menu list and you would not lose any current game information. Use the "Network/Change PIN Selected Units" menu item to assign PIN 1 to all Blue units. Use the "Network/Change PIN Selected Units" menu item to assign PIN 2 to all Red units. Do the same with "Network/Change PIN Off Map Artillery" . Do the same with "Network/Change PIN Air Support" >I would appreciate having a depot unit where I can resupply >a limited amount of all kinds of ammo. Select "Options/Enable Umpire Tools" (if necessary). Select "Orders/Do Blue, red, etc" (if necessary). Select "Options/Add One Unit". Select "+ Logistics Package" and add that marker to the map. >Unit Status information is displayed in the bottom status window >for about five seconds and then clears. Is this correct? That is correct when in Multiplayer Team Play mode. In that mode, many windows automatically close after 5 seconds of inactivity. This is done to prevent those windows from interfering with network data flow. > it didn't seem possible to allow player to magic-move TRPs I gave >them, neither with or without the relevant umpire option (instantly >reposition) checked. I think I tried all combinations of getting >orders from the player and sending updates. TRPs that are received at game startup as reinforcement type unit markers can not be magic moved once they are transformed from unit-like markers to actual TRP markers. The transformation takes place at the beginning of the first combat phase after this kind of TRP marker is placed on the map. TRPs that are created by buttons in the Artillery Support Window can never be magic moved. They can only be deleted. >When I deactivated enemy OOB thereafter, nobody, including the >umpire, could ever see a OOB again. The umpire and any observer/spectator can see all Order of Battle windows as well as the complete contents of the Game Status Report - at all times. If the "No enemy order of battle" preference is check marked, all other players are only allowed to see the Order of Battle window for their force color and those parts of the Game Status Report for their force color. >does random artillery ammunition resupply >work in multiplayer? No. Random additional airstrikes are also disabled in multiplayer team play mode. If additional arty ammo or airstrikes are desired in multiplayer team play mode then the umpire has to add them manually. The Army wanted it to work this way for their exercises. >I assume that right now you do the orders exchange with all players >(and observers) in strictly sequential order, that means one after >another, ... Correct. The umpire computer draws information from each remote computer in turn, merging that information into a new situation as each block is received. It then sends a situation update back out to each remote computer in turn. >Today we ran a seven station LAN game. >We had an average wait of about 3 minutes while data was passed. >With more machines I presume it only gets longer, but not as long > as during an Internet session! You have a LAN problem! Orders exchange on a seven player LAN should take 30 or less seconds. The Fort Knox gents are doing 20 to 30 station LAN games and their orders exchanges take less than 60 seconds. Something is dragging your LAN speed way down - that is worse even than the exchange time for an Internet game. I assume that none of your players is dialing into the game via the Internet. My best guess is that you are using one or more computers with older networking cards in them and or an older LAN hub and or an older LAN router. Network cards, hubs, and routers used to have a speed of 10 MBS. Network cards, hubs, and routers made in the last couple of years work at a speed of 100 MBS. I suggest that you get your resident computer tech to examine every network card, hub, and router on your LAN and determine which components are obsolete. >I only had one glitch when a body >didn't understand the phrase "Do not touch your mouse or keyboard >for the duration of orders being passed!" Even after causing the >failure of the cycle, he was prone to attempting to keep "using" >the mouse while idle! I can see I'm going to have fun with a >bunch of over eager students!! The v403 update is less sensitive to user interruption but it is still best that the remote players remain idle once they hear the alert sound and see the message to stand by for a situation update or to standby for orders exchange. Miscellaneous CPX/network stuff ... It is possible for a helicopter or a vehicle belonging to one player to pickup and transport a unit belonging to another player of the same force color. However this must be done very carefully or the game order of battle may be damaged. The player whose units are to be transported must not load, unload, split, join, or otherwise manipulate those units during the same orders phase in which the other player intends to load them. Doing so may cause the units to be duplicated or trashed in unpredictable ways. During an orders phase, when a helicopter or a vehicle belonging to one player instantly loads or unloads a unit belonging to another player, a hidden message is sent to the umpire and to all other players that causes this change to be instantly implemented on all computers. A marker that is loaded will instantly disappear on all computers. A unit that is unloaded will instantly appear on all computers. TacOps is not designed to run as a server based program. Every computer in a net game must have a complete TacOps installation on it. Not only the game engine, but also every support file - OpenPlay modules, maps, scenarios, etc. Network problems, mysterious hangs, crashes, and loss of game sync will eventually occur if any TacOps file (game engine, map, scenario, OpenPlay modules , saved game file, etc) is shared across a server. Users should avoid checking, sending, or receiving email during a TacOps network game session - particularly if there is any chance that an orders exchange or situation update is imminent. Users should not surf the Internet with a web browser during a TacOps game session - ever. The following programs are suspected of periodically interfering with a TacOps network on some computers if run at the same time as TacOps: Microsoft Outlook, Microsoft Word, Microsoft PowerPoint, Microsoft Explorer, and Microsoft Messenger. Some players have reported being disconnected from the TacOps network anytime that they send or receive email while using Microsoft Outlook. Any program that is run at the same time as TacOps has the potential to interfere with the TacOps network, with orders exchanges, and with situation updates. The more activity that the user does with TacOps in the background, the more likely that a network problem, an orders exchange failure, or a situation update failure will occur. Reasons: Memory shortage. System resources shortages. Hanging the network while the user browses through menu lists and modal dialogs in the program other than TacOps. Many programs contain an option or preference that causes the program to automatically access the Internet to check for an updated version of itself on a company internet site anytime that the program is started. Many programs have a help feature that accesses the Internet for help information. Many programs do not cooperate well with other programs that are running at the same time - especially programs that access the Internet. A web browser that has reached a web site, even when running in the background, may be constantly generating network traffic and running Java applets due to changing popup ads on the web site. [ October 27, 2002, 11:32 AM: Message edited by: MajorH ] 0 Quote Link to comment Share on other sites More sharing options...
LibertyOrDeath Posted October 27, 2002 Share Posted October 27, 2002 Originally posted by MajorH: TacOps Gazette 02.02 <snip> The v403 update is less sensitive to user interruption but it is still best that the remote players remain idle once they hear the alert sound and see the message to stand by for a situation update or to standby for orders exchange. <snip> Users should avoid checking, sending, or receiving email during a TacOps network game session - particularly if there is any chance that an orders exchange or situation update is imminent. Users should not surf the Internet with a web browser during a TacOps game session - ever. The following programs are suspected of periodically interfering with a TacOps network on some computers if run at the same time as TacOps: Microsoft Outlook, Microsoft Word, Microsoft PowerPoint, Microsoft Explorer, and Microsoft Messenger. Some players have reported being disconnected from the TacOps network anytime that they send or receive email while using Microsoft Outlook. Any program that is run at the same time as TacOps has the potential to interfere with the TacOps network, with orders exchanges, and with situation updates. The more activity that the user does with TacOps in the background, the more likely that a network problem, an orders exchange failure, or a situation update failure will occur. Reasons: Memory shortage. System resources shortages. Hanging the network while the user browses through menu lists and modal dialogs in the program other than TacOps. Many programs contain an option or preference that causes the program to automatically access the Internet to check for an updated version of itself on a company internet site anytime that the program is started. Many programs have a help feature that accesses the Internet for help information. Many programs do not cooperate well with other programs that are running at the same time - especially programs that access the Internet. A web browser that has reached a web site, even when running in the background, may be constantly generating network traffic and running Java applets due to changing popup ads on the web site.Would a 1 GHz P3, 384 MB RAM, 32 MB Geforce2 GTS graphics card, 56K modem, Win XP system have problems running TacOps with a IRC chat client and Yahoo Messenger in the background? 0 Quote Link to comment Share on other sites More sharing options...
MajorH TacOps Developer Posted October 27, 2002 Author Share Posted October 27, 2002 I don't have any reports of any popular IRC chat client program causing a problem while running at the same time as TacOps. I would not be surprised if Yahoo Messenger caused problems but folks should try it and see. The various messenger programs may have gotten better in the last year or so but I don't know because I have not used them in a couple of years. The last time that I tried Microsoft Messenger it constantly screwed up my PCs and siginificantly slowed them down while I was doing other work. 0 Quote Link to comment Share on other sites More sharing options...
LibertyOrDeath Posted October 27, 2002 Share Posted October 27, 2002 Originally posted by MajorH: TacOps Gazette 02.02 >I assume that right now you do the orders exchange with all players >(and observers) in strictly sequential order, that means one after >another, ... Correct. The umpire computer draws information from each remote computer in turn, merging that information into a new situation as each block is received. It then sends a situation update back out to each remote computer in turn. This answers my previous question in the CPX thread. Just how big are these files typically? 15 Kb file from each player? 150 Kb from the umpire? So in a 10 player + 1 umpire MTM game, the umpire would have to send out approx. 150 Kb x 10 of data to the players each turn? Also, is it possible to tweak TacOps so it can send a situation update back out to each remote computer not in turn, but simultaneously? 0 Quote Link to comment Share on other sites More sharing options...
MajorH TacOps Developer Posted October 27, 2002 Author Share Posted October 27, 2002 > Just how big are these files typically? It depends on how many unit markers are in play. These are not files, they are data flows and the data is compressed as it goes out so 20K to 50K per flow per player might be typical for a medium sized game. > So in a 10 player + 1 umpire MTM game, the umpire would > have to send out approx. 150 Kb x 10 of data to the players > each turn? More like 10 times 20K to 50K. > Also, is it possible to tweak TacOps so it can send a > situation update back out to each remote computer not in > turn, but simultaneously? It may be possible someday to code a reliable broadcast mode but I have not found a way to do it yet while using the OpenPlay network library. I am not a TCP/IP/Internet/LAN guru so there could be better and faster ways to do things that I know nothing about. [ October 27, 2002, 02:02 PM: Message edited by: MajorH ] 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.