Medal of Honor: Pacific Assault MP Demo #2! The Corregidor level is SWEET and it's not in the full version! Invader mode is probably the best gameplay mode I've played in a while. Not to mention that the lag issues are totally fixed. Try it out and post your opinion. A second patch will be released soon that includes all fixes and the new map in this demo. For those of you who have liked it and feel the Multiplayer game has gotten a bad rep' or has been overshadowed, go and post about it in other forums.
Download:
http://www.eagames.com/official/moh...s/downloads.jsp
Here are the Demo Contents taken from the readme:
DEMO CONTENTS
================================================== ==========
======
1. Access to 1 new multiplayer map (Corregidor)
2 Mouse and Input Lag
2. Dedicated Server CPU Utilization
3. 999 Ping Bug
4. Spawn Code Server Hitching
5. Full Screen Anti-Aliasing support
================================================== ==========
======
Full Screen Anti-Aliasing (FSAA)
================================================== ==========
======
This demo allows you to turn on full-screen anti-aliasing. To turn it on you must modify the value of the following variable:
r_multisample_quality 0 - No multi-sampling
1 - 1 x multi-sampling
2 - 2 x multi-sampling
...
16 - 16 x mutli-sampling
The software will automatically degrade the value of r_multisample_quality to the highest possible value that your hardware is capable of. In order to see the results of this change you will need to exit the game and return. Once set, the value of this variable will be preserved.
================================================== ==========
======
Addressing Mouse Lag
================================================== ==========
======
This demo improves the responsiveness of the renderer and greatly reduces
the time lag between user input (mouse movements, button clicks)
and the corresponding visual updates on-screen, and should result
in a much more responsive feel to the game as a whole. In
multiplayer games, the responsiveness is improved for all model
detail settings, but for performance reasons it only affects "medium"
and "high" model detail in single player games.
================================================== ==========
======
Dedicated Server CPU Utilization
================================================== ==========
======
win_dedicated_sleep
This cvar has a default value of 1, and will be saved to server.cfg
whenever it is changed. The cvar specifies the number of milliseconds
that a dedicated server will completely relinquish control to the operating system each frame. Increasing the value of the cvar effectively reduces the CPU utilization of a MOHA dedicated server process.
Increase this cvar if you are running multiple instances of dedicated servers
or other necessary processes on your CPU. Set this cvar to 0 if you want an
instance of the MOHA dedicated server to use the CPU whenever it is available
(100% utilization). A value of 0 can result in a slight performance increase,
especially on low spec machines with several connected users. Increasing this cvar can result in a performance decrease. You may change this cvar at runtime or at the command line; we recommend a range of 0 to 10 (integer only).
================================================== ==========
=======
Network Performance Tips
================================================== ==========
=======
If you are getting poor latency in a game, make sure your Connection Type is properly set. Leaving it at the default ISDN setting will cause lag and other performance issues.
Set your connection type to LAN, or DSL, either when you are prompted to enter your Call Sign and Connection Type the first time you click on the Multiplayer Menu, or from the Player Setup screen, accessible by clicking the button on the top right of any of the Multiplayer Menus.
================================================== ==========
=======
Optimization and Battle Ambience
================================================== ==========
=======
If clients are having latency issues on your server, you can turn some of
the ambient effects off from the console or from the DSLauncher:
• From the server console, type dm_effectscontroller 0 and this
will turn the effects off next time the server restarts.
• From the DSLauncher, go to the “Advanced 2” tab, set your
Bandwidth optimization to “Network Speed”.
• If you’re starting servers from some kind of batch file/command line,
just add +set dm_effectscontroller 0 to the shortcut.
================================================== ==========
======
Multiplayer - Spawning Performance Related Cvars
================================================== ==========
======
dm_playerspawn_method
For smaller games the server will perform spawn placement heuristics to best
determine where to place someone. The default behavior (when dm_playerspawn_method is left blank) is to use the "notfacing" spawn placement. Here is a list of all the possible values for dm_playerspawn_method:
• "random" - players will spawn in a random location. This is the least computationally expensive (fastest) method.
• "farthest" - players will spawn in the farthest location from the enemy. This method is not recommended on large maps.
• "team" - players will spawn far from the enemy, but close to an ally.
• "notvisible" - players will be placed close to enemies, but not invisible line of sight of the enemy. This is the most computationally expensive (slowest) method, and might cause performance problems with large numbers of players on slower servers.
• “notfacing” – players will be placed close to enemies, but only when the enemies aren’t currently facing where the player will spawn. This has the potential to be computationally expensive (but not as slow as “notvisible”). For this reason, by default we do not use this method once dm_playerspawn_threshhold players are on the map. This is currently the default spawn heuristic for FFA, TDM and Invader modes.
• "bufferedclose" – Players will always spawn at least 65 feet away from an enemy, but otherwise as close to an enemy as possible.
• "closest" - players will spawn in the closest spot to an enemy. This is a fine method to choose if you just want high levels of mindless carnage.
• "group" - players will spawn in the closest spot to an ally.
• "" - (default) - use whatever method is recommended for each game type. Currently we have this set as "notvisible" for FFA, TDM and Invader. But this might be fine tuned at a later date.
Admins with faster machines might enjoy raising the dm_playerspawn_threshhold to a value higher than 16. Ideally this could be set to 32, but admins of slower machines should monitor high player-count games and check to see if the server is pausing right when large numbers of players are respawning (If this is the case, then those server owners should reduce the dm_playerspawn_threshhold back down to 16).
dm_playerspawn_threshhold
This variable governs when the engine should cut over from using a computationally expensive spawn heuristic to more standard spawn heuristics. The default value is 16. If the admin sets this to 1, then the secondary spawn heuristic will always be used when there are multiple players in the game. NOTE: Some slower servers might want to consider setting this value lower than the default if the players notice a burst of server-lag each time players respawn.
dm_playerspawn_method_alt
If there are more players in the game than dm_playerspawn_threshhold, the MOHPA engine will switch from using the spawn heuristic detailed in dm_playerspawn_method and instead use the one detailed in dm_playerspawn_method_alt. The default value for dm_playerspawn_method_alt is "random" (which is the fastest spawn heuristic).
dm_playerspawn_poisontime
This cvar is provided for admins that wish to ensure that no two players spawn in the same immediate area at the same time. By default this variable is turned off (set to the value zero), but if a positive value is given, this is the number of seconds that a spawn point (and all the neighboring spawn points) will be shut down after it has spawned a player at that spawn point.
g_respawn_time
This indicates how many seconds will elapse between spawn waves. When a player dies, they must wait for the next respawn interval to pass before they are allowed to respawn. The default value is 10 (so that there are ten second periods where dead players are waiting to spawn, and then they will all respawn at once). Higher values will allow for a playstyle that resembles waves of reinforcements in team games (TDM & Invader). A value of 0 will allow players to spawn immediately after they die.
NOTE: In FFA games, if the players notice that there is a burst of server-lag when the spawn waves happens, the admin should lower this value (or even set this to zero); as the engine might be spending an inordinate amount of time computing where to best place large numbers of the respawning players at the same instant.
Download:
http://www.eagames.com/official/moh...s/downloads.jsp
Here are the Demo Contents taken from the readme:
DEMO CONTENTS
================================================== ==========
======
1. Access to 1 new multiplayer map (Corregidor)
2 Mouse and Input Lag
2. Dedicated Server CPU Utilization
3. 999 Ping Bug
4. Spawn Code Server Hitching
5. Full Screen Anti-Aliasing support
================================================== ==========
======
Full Screen Anti-Aliasing (FSAA)
================================================== ==========
======
This demo allows you to turn on full-screen anti-aliasing. To turn it on you must modify the value of the following variable:
r_multisample_quality 0 - No multi-sampling
1 - 1 x multi-sampling
2 - 2 x multi-sampling
...
16 - 16 x mutli-sampling
The software will automatically degrade the value of r_multisample_quality to the highest possible value that your hardware is capable of. In order to see the results of this change you will need to exit the game and return. Once set, the value of this variable will be preserved.
================================================== ==========
======
Addressing Mouse Lag
================================================== ==========
======
This demo improves the responsiveness of the renderer and greatly reduces
the time lag between user input (mouse movements, button clicks)
and the corresponding visual updates on-screen, and should result
in a much more responsive feel to the game as a whole. In
multiplayer games, the responsiveness is improved for all model
detail settings, but for performance reasons it only affects "medium"
and "high" model detail in single player games.
================================================== ==========
======
Dedicated Server CPU Utilization
================================================== ==========
======
win_dedicated_sleep
This cvar has a default value of 1, and will be saved to server.cfg
whenever it is changed. The cvar specifies the number of milliseconds
that a dedicated server will completely relinquish control to the operating system each frame. Increasing the value of the cvar effectively reduces the CPU utilization of a MOHA dedicated server process.
Increase this cvar if you are running multiple instances of dedicated servers
or other necessary processes on your CPU. Set this cvar to 0 if you want an
instance of the MOHA dedicated server to use the CPU whenever it is available
(100% utilization). A value of 0 can result in a slight performance increase,
especially on low spec machines with several connected users. Increasing this cvar can result in a performance decrease. You may change this cvar at runtime or at the command line; we recommend a range of 0 to 10 (integer only).
================================================== ==========
=======
Network Performance Tips
================================================== ==========
=======
If you are getting poor latency in a game, make sure your Connection Type is properly set. Leaving it at the default ISDN setting will cause lag and other performance issues.
Set your connection type to LAN, or DSL, either when you are prompted to enter your Call Sign and Connection Type the first time you click on the Multiplayer Menu, or from the Player Setup screen, accessible by clicking the button on the top right of any of the Multiplayer Menus.
================================================== ==========
=======
Optimization and Battle Ambience
================================================== ==========
=======
If clients are having latency issues on your server, you can turn some of
the ambient effects off from the console or from the DSLauncher:
• From the server console, type dm_effectscontroller 0 and this
will turn the effects off next time the server restarts.
• From the DSLauncher, go to the “Advanced 2” tab, set your
Bandwidth optimization to “Network Speed”.
• If you’re starting servers from some kind of batch file/command line,
just add +set dm_effectscontroller 0 to the shortcut.
================================================== ==========
======
Multiplayer - Spawning Performance Related Cvars
================================================== ==========
======
dm_playerspawn_method
For smaller games the server will perform spawn placement heuristics to best
determine where to place someone. The default behavior (when dm_playerspawn_method is left blank) is to use the "notfacing" spawn placement. Here is a list of all the possible values for dm_playerspawn_method:
• "random" - players will spawn in a random location. This is the least computationally expensive (fastest) method.
• "farthest" - players will spawn in the farthest location from the enemy. This method is not recommended on large maps.
• "team" - players will spawn far from the enemy, but close to an ally.
• "notvisible" - players will be placed close to enemies, but not invisible line of sight of the enemy. This is the most computationally expensive (slowest) method, and might cause performance problems with large numbers of players on slower servers.
• “notfacing” – players will be placed close to enemies, but only when the enemies aren’t currently facing where the player will spawn. This has the potential to be computationally expensive (but not as slow as “notvisible”). For this reason, by default we do not use this method once dm_playerspawn_threshhold players are on the map. This is currently the default spawn heuristic for FFA, TDM and Invader modes.
• "bufferedclose" – Players will always spawn at least 65 feet away from an enemy, but otherwise as close to an enemy as possible.
• "closest" - players will spawn in the closest spot to an enemy. This is a fine method to choose if you just want high levels of mindless carnage.
• "group" - players will spawn in the closest spot to an ally.
• "" - (default) - use whatever method is recommended for each game type. Currently we have this set as "notvisible" for FFA, TDM and Invader. But this might be fine tuned at a later date.
Admins with faster machines might enjoy raising the dm_playerspawn_threshhold to a value higher than 16. Ideally this could be set to 32, but admins of slower machines should monitor high player-count games and check to see if the server is pausing right when large numbers of players are respawning (If this is the case, then those server owners should reduce the dm_playerspawn_threshhold back down to 16).
dm_playerspawn_threshhold
This variable governs when the engine should cut over from using a computationally expensive spawn heuristic to more standard spawn heuristics. The default value is 16. If the admin sets this to 1, then the secondary spawn heuristic will always be used when there are multiple players in the game. NOTE: Some slower servers might want to consider setting this value lower than the default if the players notice a burst of server-lag each time players respawn.
dm_playerspawn_method_alt
If there are more players in the game than dm_playerspawn_threshhold, the MOHPA engine will switch from using the spawn heuristic detailed in dm_playerspawn_method and instead use the one detailed in dm_playerspawn_method_alt. The default value for dm_playerspawn_method_alt is "random" (which is the fastest spawn heuristic).
dm_playerspawn_poisontime
This cvar is provided for admins that wish to ensure that no two players spawn in the same immediate area at the same time. By default this variable is turned off (set to the value zero), but if a positive value is given, this is the number of seconds that a spawn point (and all the neighboring spawn points) will be shut down after it has spawned a player at that spawn point.
g_respawn_time
This indicates how many seconds will elapse between spawn waves. When a player dies, they must wait for the next respawn interval to pass before they are allowed to respawn. The default value is 10 (so that there are ten second periods where dead players are waiting to spawn, and then they will all respawn at once). Higher values will allow for a playstyle that resembles waves of reinforcements in team games (TDM & Invader). A value of 0 will allow players to spawn immediately after they die.
NOTE: In FFA games, if the players notice that there is a burst of server-lag when the spawn waves happens, the admin should lower this value (or even set this to zero); as the engine might be spending an inordinate amount of time computing where to best place large numbers of the respawning players at the same instant.
Facebook
Twitter
Instagram