alterware/iw6-mod
1
0
Fork 4
Code Issues Pull Requests 13 Packages Projects Releases Wiki Activity

Added code for demo system. #16

Open
anomaly wants to merge 14 commits from anomaly/iw6-mod:demo_system into master
pull from: anomaly/iw6-mod:demo_system
merge into: alterware:master
Conversation 2 Commits 14 Files Changed 44 +5167 -229
anomaly commented 2024-12-31 19:16:46 +00:00
First-time contributor
Copy Link

This pr adds demo support to IW6 by way of 9 user commands (7 for client, 2 for server) and 5 cvars (3 for client, 2 for server).
user commands:

  1. demostart:

    • record a demo
    • shows red recording text in the lower left corner
    • takes two optional argument:
      • <filename> is used as demo file name
      • overwrite to indicate that overwriting an existing demo file is allowed,
        this only applies if the user provided the file name
    • if no argument is provided, the next available file name is used

  2. demostop:

    • stop recording the current demo, if any
    • removes the recording text

  3. demoplay:

    • play a demo
    • takes an argument for the demo file name
    • takes an additional two optional arguments:
      • fullpath to indicate that the second argument is not the demo file name but "path/filename.extension"
      • repeat to keep playing the demo, instead of stopping the playback the demo will rewind to the beginning

  4. demoinstantplay:

    • same functionality as demoplay but experimental
    • can be used to play demos even when connected to a local or online server,
      without spending time on disconnecting or map (re)loading
    • it's possible to play a demo that's still recording
    • any server connection will be lost and any demo recording will stop

  5. demoreplay:

    • replay the last played demo

  6. demoforward:

    • takes an argument for the time in milliseconds to skip forward

  7. demorewind:

    • takes an optional argument for the time milliseconds to rewind
    • if no argument is provided, the demo rewinds to the beginning

  8. sv_demostart:

    • similar behavior as demoplay
    • takes 3 arguments:
      • <client_num | player_name>
      • <filename> and overwrite are optional
    • client num can be indicated by pidX like pid10,
      there can be any number of zeroes between pid and X (pid0010)
      to differentiate between actual pids and player names

  9. sv_demostop:

    • takes one argument for client num or player name
    • <client_num | player_name> argument behavior is the same as sv_demostart

cvars:

  1. demotimescale:

    • takes a argument between 0 and 1000 to increase or decrease the demo playback speed
    • an argument with the value 0 pauses the demo playback

  2. demoautorecord:

    • if enabled, the match will be recorded automatically

  3. demovision:

    • override the current vision set with another:
      0 "disabled", 1 "no vision", 2 "default",
      3 "ac130", 4 "ac130_enhanced_mp", 5 "ac130_inverted", 6 "aftermath",
      7 "aftermath_glow", 8 "aftermath_post", 9 "black_bw", 10 "cheat_bw",
      11 "coup_sunblind", 12 "default_night", 13 "default_night_mp", 14 "end_game",
      15 "missilecam", 16 "mpintro", 17 "mpnuke", 18 "mpnuke_aftermath", 19 "mpoutro",
      20 "near_death", 21 "near_death_mp", 22 "nuke_global_flash", 23 "thermal_mp",
      24 "thermal_snowlevel_mp", 25 "aftermath_map" (only available for a small number of maps)
    • switching between vision sets can be done at any time
    • the game shouldn't override user vision despite game events triggering certain vision sets

  4. sv_demos:

    • the server demo code only executes if this cvar is enabled, to avoid wasting hardware resources
    • if this cvar was enabled after a player has joined the server,
      then that match cannot be recorded for that player

  5. sv_demoautorecord:

    • if enabled, the match will be recorded automatically for all players
This pr adds demo support to IW6 by way of 9 user commands (7 for client, 2 for server) and 5 cvars (3 for client, 2 for server). user commands: 1. `demostart`: - record a demo - shows red recording text in the lower left corner - takes two optional argument: - `<filename>` is used as demo file name - `overwrite` to indicate that overwriting an existing demo file is allowed, this only applies if the user provided the file name - if no argument is provided, the next available file name is used 2. `demostop`: - stop recording the current demo, if any - removes the recording text 3. `demoplay`: - play a demo - takes an argument for the demo file name - takes an additional two optional arguments: - `fullpath` to indicate that the second argument is not the demo file name but "path/filename.extension" - `repeat` to keep playing the demo, instead of stopping the playback the demo will rewind to the beginning 4. `demoinstantplay`: - same functionality as `demoplay` but experimental - can be used to play demos even when connected to a local or online server, without spending time on disconnecting or map (re)loading - it's possible to play a demo that's still recording - any server connection will be lost and any demo recording will stop 5. `demoreplay`: - replay the last played demo 6. `demoforward`: - takes an argument for the time in milliseconds to skip forward 7. `demorewind`: - takes an optional argument for the time milliseconds to rewind - if no argument is provided, the demo rewinds to the beginning 1. `sv_demostart`: - similar behavior as `demoplay` - takes 3 arguments: - `<client_num | player_name>` - `<filename>` and `overwrite` are optional - client num can be indicated by `pidX` like `pid10`, there can be any number of zeroes between `pid` and `X` (`pid0010`) to differentiate between actual pids and player names 2. `sv_demostop`: - takes one argument for client num or player name - `<client_num | player_name>` argument behavior is the same as `sv_demostart` cvars: 1. `demotimescale`: - takes a argument between 0 and 1000 to increase or decrease the demo playback speed - an argument with the value 0 pauses the demo playback 2. `demoautorecord`: - if enabled, the match will be recorded automatically 3. `demovision`: - override the current vision set with another: 0 "disabled", 1 "no vision", 2 "default", 3 "ac130", 4 "ac130_enhanced_mp", 5 "ac130_inverted", 6 "aftermath", 7 "aftermath_glow", 8 "aftermath_post", 9 "black_bw", 10 "cheat_bw", 11 "coup_sunblind", 12 "default_night", 13 "default_night_mp", 14 "end_game", 15 "missilecam", 16 "mpintro", 17 "mpnuke", 18 "mpnuke_aftermath", 19 "mpoutro", 20 "near_death", 21 "near_death_mp", 22 "nuke_global_flash", 23 "thermal_mp", 24 "thermal_snowlevel_mp", 25 "aftermath_map" (only available for a small number of maps) - switching between vision sets can be done at any time - the game shouldn't override user vision despite game events triggering certain vision sets 1. `sv_demos`: - the server demo code only executes if this cvar is enabled, to avoid wasting hardware resources - if this cvar was enabled after a player has joined the server, then that match cannot be recorded for that player 2. `sv_demoautorecord`: - if enabled, the match will be recorded automatically for all players
anomaly added 14 commits 2024-12-31 19:16:47 +00:00 
Replaced all occurrences of 0x0 with 0 for consistency.
Added missing includes to the list of standard headers.
Added an assertion to the asmjit assemble function to get an early warning if asmjit fails silently.
Without this workaround my fps occasionally exceeds 1500 or even 2000 fps.
Includes client and server recording code, and playback code.
anomaly commented 2024-12-31 19:46:24 +00:00
Author
First-time contributor
Copy Link

Some notes (in no particular order):

  1. most testing was done in a local server against bots on showtime / shipment team deathmatch,
    extinction mode appears to work but is mostly untested
  2. mods may work, but it's completely untested
  3. the demo file extension is .dm_iw6
  4. currently, the first bytes of each demo should contain in plain text the following data:
    (part of the general header):
    • date + time
    • demo description (client or server)
    • demo code version
    • protocol
    • build number
    • server host name
    • player name
    • ui map name
    • ui game type
      (part of the mod header):
    • mod name (based on fs_game)
      (part of the map header):
    • map name
    • game type
  5. so-called 'demo lag' upon demo file creation shouldn't be an issue with the current implementation
    (this is known to happen with other Call of Duty games, and gets worse with slower hard drives and more demo files)
  6. the game is always capturing data, even when the user is not recording a demo
    when a user starts a demo, a second demo file is created that contains the entire match up until that point
    this means that if a user never records a demo, no files are created,
    but as soon as the user starts recording a demo,
    the data for the first part of the match is stored in a secondary demo file as backup
    the second file contains everything from the match start to end
  7. occasionally there are some very minor issues with rewinding,
    but they can be worked around by restarting the demo, which is also quite fast
  8. there's support to open demos files with iw6-mod.exe
  9. all internal data types are set up as follows: type & size, which takes either 1 + 1 or 1 + 4 bytes
    this makes it easier to parse the demo as well as add new data later if needed
  10. the implementation to support 'mid-match' demos (i.e. being able to start a new demo at any time) is a bit crude,
    but the proper way to do this, i.e. imitating the logic inside SV_SendClientGameStateInternal,
    requires significantly more effort and time, and possibly make the code more game specific
Some notes (in no particular order): 1. most testing was done in a local server against bots on showtime / shipment team deathmatch, extinction mode appears to work but is mostly untested 2. mods may work, but it's completely untested 3. the demo file extension is `.dm_iw6` 4. currently, the first bytes of each demo should contain in plain text the following data: (part of the general header): - date + time - demo description (client or server) - demo code version - protocol - build number - server host name - player name - ui map name - ui game type (part of the mod header): - mod name (based on `fs_game`) (part of the map header): - map name - game type 5. so-called 'demo lag' upon demo file creation shouldn't be an issue with the current implementation (this is known to happen with other Call of Duty games, and gets worse with slower hard drives and more demo files) 6. the game is always capturing data, even when the user is not recording a demo when a user starts a demo, a second demo file is created that contains the entire match up until that point this means that if a user never records a demo, no files are created, but as soon as the user starts recording a demo, the data for the first part of the match is stored in a secondary demo file as backup the second file contains everything from the match start to end 7. occasionally there are some very minor issues with rewinding, but they can be worked around by restarting the demo, which is also quite fast 9. there's support to open demos files with `iw6-mod.exe` 9. all internal data types are set up as follows: type & size, which takes either 1 + 1 or 1 + 4 bytes this makes it easier to parse the demo as well as add new data later if needed 10. the implementation to support 'mid-match' demos (i.e. being able to start a new demo at any time) is a bit crude, but the proper way to do this, i.e. imitating the logic inside `SV_SendClientGameStateInternal`, requires significantly more effort and time, and possibly make the code more game specific
anomaly commented 2024-12-31 19:48:35 +00:00
Author
First-time contributor
Copy Link

Known issues (at this point):

  1. the playback of (killstreak reward / ksr) controlled vehicles may look slightly different,
    e.g. with the Helo Pilot ksr, the view of the chopper inside and the bullet fire / tracers will look a bit different
    the replay of modded vehicles is untested and may not work properly,
    only the Trinity Rocket, Gryphon, Helo Pilot and Loki / Odin have been tested
  2. data related to rank / unlocks are also stored in the demo, so demo playback may affect one's rank / unlocks
  3. errors when switching from extinction mode directly (without disconnecting) to multiplayer mode and vice versa:
    [FS] Startup Error: Couldn't load player animation script mp/playeranim_al_defines.script
    [FS] Startup Error: Couldn't load player animation script mp/playeranim_mp_defines.script
Known issues (at this point): 1. the playback of (killstreak reward / ksr) controlled vehicles may look slightly different, e.g. with the Helo Pilot ksr, the view of the chopper inside and the bullet fire / tracers will look a bit different the replay of modded vehicles is untested and may not work properly, only the Trinity Rocket, Gryphon, Helo Pilot and Loki / Odin have been tested 2. data related to rank / unlocks are also stored in the demo, so demo playback may affect one's rank / unlocks 3. errors when switching from extinction mode directly (without disconnecting) to multiplayer mode and vice versa: `[FS] Startup Error: Couldn't load player animation script mp/playeranim_al_defines.script` `[FS] Startup Error: Couldn't load player animation script mp/playeranim_mp_defines.script`
This pull request has changes conflicting with the target branch.
  • src/client/component/colors.cpp
  • src/client/component/party.cpp
  • src/client/game/structs.hpp
  • src/client/game/symbols.hpp
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u demo_system:anomaly-demo_system
git checkout anomaly-demo_system
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Future
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: alterware/iw6-mod#16
No description provided.
Delete Branch "anomaly/iw6-mod:demo_system"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?