In OpenArena, a demo is a "recording" of a match, stored in file that can be later played by the game. This means that you can record your matches (from your own point of view when you are playing, or from someone else's point of view when you are spectating) and watch them later, inside OpenArena. If you wish, you can send the demo file to friends of yours that use the game.
Demo playback elaborates 3D graphics in real-time (the machine does not work like when watching a movie, but like when playing the game): this allows demo files to maintain reasonable size, but they can be played only using OpenArena, and demos recorded with too much different versions of the game may have compatibility problems. However, it is possible easily to "export" demos to "movies" in .avi format (third party software later needed to play and modify AVI video files).
A demo file has got an extension like .dm_XX, where XX is a number that changes when major updates to the game change the protocol version, for example a demo recorded with OpenArena 0.8.5 (which uses protocol 71) will have a .dm_71 extension.
All the demo files you record one way or another will be saved to a "current-mod/demos" subfolder under your "homepath folder", for example "~/.openarena/baseoa/demos/" (under Linux) or "~/Application Data/Open Arena/baseoa/demos/" (under Windows XP). If you are in one of the mods, for example CPMA, the demo directory is "cpma/demos/" instead of "baseoa/demos/". The demo files in the demos directory will show up in the demo list when you choose the "Demos" menu item.
Classic way of recording a demo Edit
To record your own demo, you can pull down the command console and type /record command. To end the recording, pull down the console again and type /stoprecord.
This creates files with dumb names, like "demo0001.dm_71", automatically incremented (anyway you will be able to change them later using your operating system).
If you wish, you can use /record <filename> (file extension is automatically added) to specify a name to use (e.g. /record mytest will create a mytest.dm_71 file); if manually specifying an already existing demo name, that file will be overwritten without warning.
During recording, you will see file name and size in the upper edge of the screen.
Instead of using the console each time, you can bind two keys which you can use to start/stop the recording, for example:
/bind o "record" /bind p "stoprecord"
This method is good for short demos.
Smarter way of recording a demo Edit
Use the following bindings instead if you want a new file to be started each time a game starts, so each game will be in its own file (obviously, you may also manually enter the commands by using the console instead of binding them to specific keys):
/bind o "cl_autoRecordDemo 1" /bind p "cl_autoRecordDemo 0;stoprecord"
This creates files with rich names, which contain the date, time, ip of the server you are connected to, and map name, which is useful.
Entering /stoprecord command while cl_autoRecordDemo is still enabled will end the current demo file and will continue the recording on a new file.
Automatically recording all your games Edit
If you want all your games to be recorded, each in its own file, use this command, which will make a persistent setting:
/seta cl_autoRecordDemo 1
To disable it, use /seta cl_autoRecordDemo 0 (and then use /stoprecord to stop the current recording).
Recording a best-quality demo Edit
Before you start reading this section, take in account this stuff is very relevant for the original Quake III Arena, but in OpenArena it looks like there is no need to enable g_synchronousclients at all: demos look smooth without the need to apply any tweak. So, you may skip this part (however, as an id Tech 3 user, you may be interested into knowing what this is about).
When you start recording, you will probably get a warning in the console, "WARNING: You should set 'g_synchronousClients 1' for smoother demo".
If you leave it to 0, the demo might look crappy when viewed later. To record a best-quality demo, g_synchronousClients has to be set to 1, and has to remain 1 until you stop recording! Attention, using tricks like 'g_synchronousClients 1;record;g_synchronousClients 0' has no effect, it's the same as using 'record'! This is because g_synchronousClients change the way the game engine works, and if you start recording and then set g_synchronousClients to 0, it will act accordingly. Anyway, this trick is sometimes used to avoid warning and cases where the engine refuses to start a record if you are not synchronized, in these cases this trick can be useful (see below on how to record an AVI).
Why don't we leave it to 1 all the time, then? Well, the problem when g_synchronousClients is set to 1 is that when you play, the gameplay will feel laggy. This is because when g_synchronousClients is enabled, the client (you) will send its actions to the server (as usual), but then it will wait for all the other clients to also send their actions, and then the response of the server updating the world state. This way, you are completely synchronized not only with the server but with all other clients, but at the cost of being very laggy.
So if you want to record a best-quality demo of a game you play, you should have a spectator (it can be even you on a second computer) spectating you, and that spectator will have to set g_synchronousClients to 1 and record the demo.
Use this binding to toggle g_synchronousClients:
/bind i "toggle g_synchronousClients"
This way, you will enable or disable g_synchronousClients each time you will press the "i" key.
Trivia: variables that begin with "g_", usually are serverside. Despite its name, g_sychronousclients is a clientside variable instead.
By the way, problems of "not smooth" demos seem to affect those recorded in the originall Quake 3 Arena, but not those recorded in OpenArena... it seems there is no need to enable g_synchronousclients to get smooth demos in OpenArena.
Sv_fps and better quality demosEdit
Okay, we said that without g_synchronousclients during recording, the playback may be not smooth, and that with that enabled, game controls would not respond perfectly. A trick that you may use while playing offline -by yourself- may be to set sv_fps the same as your com_maxfps value (or anyway a value high enough for a smooth movement) while recording: if you are not using g_synchronousclients, it should give you a smoother playback... if you are using g_synchronousclients, it may give you better control responses. Not sure if such high sv_fps values (default is just 20) may give problems on an actual internet game server, due to too much data transmitted. <Please write here more infos about this, e.g. what happens with different kinds of game physics...>.
By the way, problems of "not smooth" demos seem to affect those recorded in the original Quake 3 Arena, but not those recorded in OpenArena... it seems there is no need to enable g_synchronousclients to record smooth demos in OpenArena, and no need to tweak sv_fps for demos.
Playing a demo Edit
From OA main menu, you can access the "demo" menu and see the list of demos to select from. The demo browser in v0.8.x may be not too comfortable, if you have a lot of demos and they have long file names.
You can use this command to play a demo:
Use TAB completion when writing the filename. This will work on the demos in the "baseoa/demos/" directory.
On Linux, you can use this script to easily play a demo: http://openarena.ws/board/index.php?topic=2327.msg18231
You can try to play a demo recorded on Q3A (e.g. using a specific mod, to have the same gamecode) or another OA version, which uses a different protocol number (e.g. Q3A 1.32 uses .dm_68 extension) by specifying the filename complete with extension (e.g. /demo mydemo.dm_68); the original Q3A does not allow this, and one would need to change the extension of the file at filesystem level, to be able to play a demo recorded with a different protocol version. Compatibility should remain in future, but we can't assure it. Note: you must have the same map on both games.
When playing a demo, the only thing you can do is to bring down the console. Any other key you press will take you out of the demo.
It is possible to set \timescale <number.dec> (default value is 1) to change playback speed. 1 means standard speed; higher values mean faster playback (e.g. 1.5 for 50% faster playback, 2 for 100% faster playback -2x speed-), and lower values mean slower playback (e.g. 0.5 means 50% slower playback, and 0.1 means 90% slower playback -10% speed-). This can be useful to quickly reach the part of the demos you are interested to, and to watch the action in suggestive slow-motion. Each single audio event will be played at its usual speed, but they will be played in the right moment, closer or away each other in time, according to the selected playback speed. When done, set timescale back to 1. If you play demos often, you may find very useful binding different timescales to specific keys, or to single keys with toogle!
It is possible to set \cl_freezedemo 1 (deafult value is 0) to "stop" the screen at the current frame (and sound stops, too), but the demo will continue to run on background: when you will set cl_freezedemo to 0 again, you will notice the demo will jump ahead.
It is possible to set \com_cameraMode 1 (default value is 0) to do not make the demo quit by simply pressing a button anymore. More, enabling it hides your player model drawing if \cg_thirdperson is set to 1.
Note: currently, demo files do not contain infos about files in use when recording (e.g. which version of a certain map that may have been modified across different OpenArena patches). This can bring to compatibility problems varying from small to critical, if you try to play a demo recorded with an OpenArena version (e.g. recorded while connected to a server that uses a previous version) while using a different OpenArena version. If you have OpenArena 0.8.8 and need to play an OpenArena 0.8.5 or 0.8.1 demo, you should temporary disable 0.8.8 and 0.8.5 patch pk3 files, e.g. by renaming pak6-patch085.pk3 to pak6-patch085.pk3.bak, then launch the game, watch the demo, then close the game and restore the correct name of the patch file.
Tip: if you wish to continue being capable of seeing your match recording at any time in the future, remember that it is possible to export demos to .avi video files (of course, videos are technically very different from demos).
TODO: Mention commands which can be useful when playing a demo: changing point of view.
Timedemo: use demo as benchmarkEdit
It is possible to use the game as an hardware benchmark tool. To do it, set /timedemo 1 (default value is 0), then play a demo (as usual, with the /demo <demoname> command): that demo will be played at the maximum possible speed (e.g. a demo that usually plays in one minute could be played in three seconds); after playback end, pull down the console to read the average fps count (frames-per-second, higher is better); at the end, set timedemo to 0 again. You can repeat the same test with different graphic settings, and/or copy the same demo file to more machines (where you should set similar graphic settings), write down somewhere the results and compare them to figure out which hardware works better with the game.
Benchmarking with different settings on the same machine may help you to find the best ratio of quality settings/speed for you; anyway, remember that when not running a timedemo, your maximum frames-per-second limit is limited by your com_maxfps setting (a variable that you should keep on a fps value your machine can manage constantly), see Graphic options#Framerate.
OpenArena 0.8.8 includes a pre-defined demo, that can be used as a common base to allow all 0.8.8 users to run a benchmark using the same demo. It is named "demo088-test1"; you can run it like any demo.
Comparing different systems could be not too easy, cause of the huge number of options that could be differently set on players configurations. A way to do it could be to start both machines with a "clean" OpenArena configuration (this way, both of them will have the same default settings active), and then run the same demo file with the same settings. Then you could do the same configuration changes on both computers and repeat the test. Once finished, restore your original custom configuration. Note: OpenAL sound system is enabled by default, but is only effective if the system has this component installed, otherwise SDL sound system is used; normally it should not have a big effect on performances, but you may want to try both with it enabled or disabled.
If you need a step by step guide for comparision of two machines (repeat the same on both; pay attention to do not delete your working configuration by error):
- Locate your "baseoa" folder in your "homepath folder" (if using Windows, it's %appdata%\OpenArena\baseoa; see Homepath for more info), which contains your "q3config.cfg" file.
- Rename "q3config.cfg" to "q3config.cfg.sav", or to "q3configGOOD.cfg" or whatever you wish.
- If you have an "autoexec.cfg" file, you can rename it to "autoxec.cfg.sav" or "autoexecGOOD.cfg" or whatever you wish.
- Launch OpenArena. It is now using default configuration.
- Set /timedemo 1.
- Play the demo you wish, and at the end check the resulting FPS in console.
- If you wish, change some settings in configuration (e.g. use an higher resolution, better texture quality, etc. -see Manual/Graphic options-) and repeat the test.
- When you finish, close OpenArena.
- Now delete the current "q3config.cfg" file (or rename it to "q3config.cfg.test" or similar, if you prefer), and then rename "q3config.cfg.sav" (or "q3configGOOD.cfg" or whatever you called it) and -if you had it- "autoexec.cfg.sav" (or "autoexecGOOD.cfg" or whatever you called it) to their original names (q3config.cfg and autoexec.cfg). This way, you will restore your own configuration.
Using demos against suspect cheatersEdit
Cheating is a bad habit, which can ruin the enjoyment of game for all players (including the cheater himself: what's the satisfaction in winning by cheating?). Cheaters may be kicked or banned from servers.
Demos can help finding out if someone is cheating. If you suspect someone in cheating, you can spectate him to observe his playing style more closely. Recording a demo while doing that allows you to look at it again, more carefully... and also to have the proof for your accusations against him... or to ask an opinion from someone else.
So, you spectate a suspect cheater for a while and record it. Later you re-watch the demo, trying to notice unnatural movements, inhuman accuracy and reaction times (possible "auto aim" hack known as "aimbot"), perfect knowledge of other players' positions even if they are hidden by solid walls (possible "see trough" cheating known as "wall hack").
Note: sometimes it may be hard to tell apart cheating from great skill, legit guessing others' actions and lucky shots. Be careful before accusing someone of cheating.
To recognize "wall hacks", while playing back the demo you can enable either r_showNormals or r_showTris variables (1 enables; default is 0, disabled). They are cheat-protected cvars which allow you to spot items, players and geometry in general even behind walls, more or less similarily to how a "wall hack" cheater would. They do not allow to see inside areas which are not rendered due to VIS optimization.
Also tweaking timescale to make the demo playback run faster or slower may come handy. You may wish to bind some keys to change it quickly when necessary.
Export to a video file Edit
How to create a movie AVI file starting from a demo Edit
See also: Makeavideo
Of course you may prefer to use the third party screen recording program you wish for the task, e.g. for capturing directly into your preferred codec... however ioquake3 allows to create an AVI file from a demo directly from the game, in an easy way.
The process is very straitghtforward:
- 1- Record a demo: see recording instructions above;
- 2- Watch the demo and save to a movie file:
/demo "<demoname>" // Replay the recorded demo named "<demoname>" /video "<videoname>" // While a demo is replaying, save what is watched to a movie file named "<videoname>".
You do not have to specify ".avi" extension at the end of the name, it will be added automatically. Your video will be created under <your homepath>\<baseoa or mod name>\videos\ directory. If no video name specified, /video command will automatically create a file like video0000.avi, video0001.avi, video0002.avi, etc.
Pressing ESC key (or many other keys while the console is closed) will terminate demo playing and video exporting before the end of the demo. /Stopvideo command, instead, will stop exporting the demo, but continue reproducting it.
Tip: it is possible to bind /video and /stopvideo to specific keys.
To tweak the movie settings:
/cl_aviMotionJpeg <0 or 1> // this cvar controls which format the AVI file is created in - set it to 0 for uncompressed video (uses insane amounts of hard drive space) or set it to 1 for Motion Jpeg which is more space efficient, but lower quality. Default value is 1. /cl_aviFrameRate <number> // This is the frame rate that the AVI is created at, higher values make the video appear smoother when playing back but need more CPU power. Default value is 25 (like PAL TV), and should be fine for most people (Hollywood movies are recorded at 24 FPS, and NTSC TV is about 30 FPS).
- If command console is open during playback, it will be shown in the video, too.
- If OpenAL sound system (an advanced audio software library that OpenArena can use) is installed and enabled, the video will not contain audio. If you want your video to include audio, you have to disable OpenAL, if you were using it. If you already had /s_useopenal 0, you are okay... if you had it set to 1, instead, you have to set it to 0, then either type /snd_restart in console or completely close and launch OpenArena again, and then export your video, complete with sound. After you finished, if you want, you can enable OpenAL again (1 is its default value). Sound will be saved in uncompressed PCM format, anyway you can later convert to the codec you wish (MP3, AC3, etc.) using third-party software, just like you can do with the video stream.
- If, when you playback the movie file, find video and audio not synchronized, you may just try use a different media player software, or try to use a format converter tool, to convert the video file (this may fix audio sync).
- An user reported his exported video was played faster than it should. He mentioned it worked corretly after re-exporting it at a lower resolution.
This is all you need to know to make your first OA movie, but you can make your life easier and your videos quality better with some scripts and settings.
Scripts and settings for movie Edit
Recording a movie from the beginning of the demoEdit
Exporting to a movie starting from the beginning of the demo is very easy: simply type the following command in the console:
/demo "<demoname>" ; video "<videoname>"
This will replay the demo and immediately, after the map loads, will start recording a movie.
When recording a demo, you may find that sometimes the console prompts you to be synchronized. This is logical because you need to be synchronized to other players to be able to faithfully record the actions (even if it's not a server-side demo).
This is simply fixed by setting:
/g_synchronousClients 1 // Synchronize your client to the other clients (wait for the server feedback before updating your local world state)
The first problem is that is a server-side variable, so you can only change its value if you are the server admin, and it affects all players.
The second problem with g_synchronousClients is that it will make you lag a lot, because you will have to wait for the server's confirmation of every player's move before your world gets updated. If you are spectating, then that's no problem, but if you are playing while you're recording your demo, this can be pretty frustrating. You may feel control responses a bit off, for example you may have problems trying to do rocket jumps.
An easy way to workaround that is to use a script that will automatically toggle this cvar just before recording, so that the game accepts to record, and then toggle it off. Theoretically, with g_synchronousClients 0 your recording can have some quirks (because you are recording unsynchronized with the server), but concretely, you will see no difference in the resulting demo (furthermore with delag, clients get almost always a full integrity of the data).
Copy/paste the following code into your q3config.cfg:
bind F12 "vstr recorddemo" set recorddemo "vstr recorddemostart" set recorddemostart "set g_synchronousClients 1;set cl_autoRecordDemo 1;set g_synchronousClients 0;set recorddemo vstr recorddemostop;echo ^2Demorecording ^2Started!;echo ^2Do ^2Not ^2Forget ^2To ^2Stop ^2Demo ^2Before ^2Exiting ^2Game!" set recorddemostop "set cl_autoRecordDemo 0;stoprecord;set g_synchronousClients 0;set recorddemo vstr recorddemostart;echo ^2Demorecording ^2Ended!"
This will bind to the key F12 the record action. Just press F12 to start recording, and press again F12 to stop recording. Of course, you can bind to any other key that you prefer.
Note: the "sync every frame" graphic option does not refer to g_synchronousClients, however it may help with some input lag problems.
Saving the movie in a different drive than the OA user folderEdit
You may find it very annoying that you can't specify the fullpath where to save your movie (example: you may want to use a drive where you have more free space available).
To circumvent that, you can specify a homepath where the game should store all of its data. This is very easily done: when launching the game at commandline, add the following argument:
+set fs_homepath "<your_new_path>"
So you will get something like this:
./openarena.i386 +set fs_homepath "L:/openarena/"
Enhance the graphical quality of the movieEdit
See also: Manual/Graphic options.
The graphical quality of your movie will be directly dependent of your graphical game settings. This means that before saving your movie, you should set all your graphical settings to Very High, and activate the optional graphical parameters such as Anisotropy and Boom Effect (if you like it). An example of settings:
seta s_useOpenAL 0 seta cg_drawSpeed 0 seta cg_drawFPS 0 seta r_bloom 1 seta r_picmip 0 seta r_flares 1
The resolution (r_mode) is also an important parameter: higher the resolution, finer will be the recording (but bigger will be the filesize, so be prepared!). Also, an important thing to note is that higher the resolution, smaller will be the chat lines, so if it's important to you to record the chatlines (if for example you're recording a tutorial video, you may find it useful to use a small resolution). Also, you can get a pretty decent fine video by having a small resolution but a high anisotropy.
seta r_mode "0" // resolution of the screen : -1=custom (see r_custom*) ; 0=340x280 ; 1=420x340 ; 2=530x420 ; 3=640x480 ; 4=800x600 ; 5=1024x768 ; etc...
For widescreen, you can also play with the r_mode parameter.
seta r_mode "-1" seta r_customaspect "1" // enables custom aspect of the screen, with r_mode -1 seta r_customheight "768" // custom screen height with r_mode -1 (useful for widescreens) seta r_customwidth "1366" // custom screen width with r_mode -1 (useful for widescreens)
Also, remember that higher the resolution, slower your video framerate will be, unless you have a very powerful CPU. Generally, it is preferable to have a lower resolution and higher, smoother framerate (which defines the smooth of the movements), rather than a high resolution with jittering movements.
Lastly, you can play with the video specific parameters:
seta cl_aviMotionJpeg 1 // this cvar controls which format the AVI file is created in - set it to 0 for uncompressed video (uses insane amounts of hard drive space) or set it to 1 for Motion Jpeg which is more space efficient, but lower quality. Default value is 1. seta cl_aviFrameRate 25 // This is the frame rate that the AVI is created at. Default value is 25.
If you set cl_aviMotionJpeg 0, you will get a raw (uncompressed) video. If you can allow it (you have a lot of space, roughly 1 GB per minute of video), then this is the preferable option. You can later recompress the video by yourself with high quality encoders such as H264. But if you can't, compressing into Motion JPEG is still a good compromise and give a good quality. Of course, you may later convert it to the format/codec you prefer (e.g. Xvid, Ogg, QuickTime...) using third-party software.
About the frame rate that the AVI is created at, higher values make the video appear smoother when playing back but need more CPU power. Default value is 25 (like PAL TV), and should be fine for most people (Hollywood movies are recorded at 24 FPS, and NTSC TV is about 30 FPS). You may want to use an higher framerate if you are planning to later use non-linear video editing software to create a movie including high quality slow-motion sections.
Removing the HUDEdit
You can simply bind cg_draw2D to a key:
/bind F10 toggle cg_draw2D
This will allow you to quickly remove the HUD while recording a part of a demo, and quickly toggle it back when you're finished. Of course, you can bind the key you prefer instad of F10, and in general binding to a key is not mandatory (you can enter the /cg_draw2d <0 or 1> command manually).
After saving the video Edit
Now that you have your movie file, you can reencode it to another format to compress it, or add some editing like motion blur with video editing softwares such as VirtualDub or Adobe After Effect.
You can also use third-party tools to watch your demos with added graphical effects such as OAmme (eg: motion blur, slow motion, etc.).
You can also find a good tutorial about video recording here: http://rainbow.furver.se/index.php?name=Forums&file=viewtopic&t=1152
Export to a sequence of image filesEdit
TODO: How to export a demo to a series of screenshots.
It looks like that the original Q3A had /cl_avidemo xx (where xx is the number of frames you wish to capture each second) which you could set before (or maybe also during) playing back a demo in case you wanted to export the demo to a series of tga images (up to 10000 images due to the file naming scheme): see here.
It looks like somewhere ioquake3 removed the feature (e.g. due to its limitations and the large size of the tga images), so it isn't available in OpenArena.
Maybe it may be possible to emulate something similar by writing a script; according to this, cl_noprint 1 may come handy doing it.
Some tests should be made... possible ideas for a such script may mean making am infinite loop similar to a map rotation screen, but with "screenshot" (or better "screenshotjpeg") instead of "map" command. And maybe the "wait" command may be used to control the framerate of the output...
A server-side demo is a demo where all players' actions were recorded, as opposed to a standard demo where only the player recording the demo is recorded (or the player spectated by the player recording).
Concretely, when you watch a server-side demo, this is just like you are a spectator of a live game: you can usually freely fly around as spectator or follow specific clients from their viewpoint, just like the game would take place right now (though you can not join).
How it works Edit
Normal client-side demo files (with .dm_XX extension) are just a dump of incoming network data on a client. Therefore they only include what this client saw (either from his perspective or the player he spectated).
The server on the other hand has full information about all players in the game.
To record a server-side demo, you either need to patch your server or use a mod that supports a similar feature.
Generally, to replay them, the clients need either to patch their engine, or to use the mod that recorded the demo (although there's one type of server-side demo that produces standard demo and thus can be played with a standard OpenArena install without any mod nor patch, see below).
Types of server-side demos Edit
There are three types of server-side demos:
1- Fully server-side demo: the demo is recorded by the server with the data the server has, by recording all entities state, actions and events. With this type of demo, all players' actions and positions are recorded and are very precisely reflecting what was processed by the server. This may be slightly different from what the players saw - particularly with delag and timenudge, because the server-side demos don't account for them (but this may theoretically be implemented in the future). To record and replay these demos, you need to apply a special patch (modification) of the game. Currently, the only existing implementation can be found here: OpenArena server-side demo patch or here . You can obtain these demos from the server's administrator.
2- Server-side demo per client: this is similar to the first kind, but instead of recording everything in a single demo file, every player is recorded separately in its own demo file. Pros: the demos produced are totally standard and so they can be played on a standard OpenArena install without any modification. Cons: it's not possible to freefly nor to switch the view (can't follow another player), unless you stop the demo and play the other player's demo you want to view. This implementation can be found here: TheDoctor's server-side demos patch or here .You also need to obtain these demos from the server's administrator. Note: with this patch, recording of a player only triggers if the player reach a certain score threshold (0.9*fraglimit), so it may happen that not all clients are recorded (but you can edit this in the code).
3- Multiview demo, alias all clients-side demos: the server does not record the demo, but redirects every flux it gets from every player to a single player (the multiview recorder), which is recording all the flux. With this type of demo, the resulting demo is not really a server-side demo since it was not recorded by the server but redirected to a player who is recording the demo. The result is about the same: you get all players' actions, but this may result in a lesser fidelity since the client recording also have some delay that he may not be able to take fully in account while recording the demo (eg: if the multiview recorder is lagging, he may lose some packets and all the players will appear to be lagging in the resulting demo, even if they weren't). Also, you can't freefly (move freely around the game as a real spectator) in a multiview demo. The name Multiview demo is derived from a feature called Multiview that you can find in some mods such as ExcessivePlus and CPMA which allows spectators to watch multiple players at once on a single screen divided into a grid of 3x3, 4x4 or 5x5 cases. Examples of mods producing multiview demos include CPMA and ExcessivePlus (the latter having facilities to replay the players' delay). To get such a demo, you need to ask the player that recorded the multiview demo.
How to use/watch a server-side demo Edit
To watch a server-side demo, it depends on how the type of the demo:
- Type1 (fully serverside): you need a patched engine to watch these demos, and use special commands (such as fulldemo_play, see the readme )
- Type2 (serverside divided per client): they are just standard demos, you can watch them with a standard OpenArena install without any patch.
- Type3 (multiview demo with a mod): you need to load the mod that recorded the demo prior to replay them. Every mod encode these multiview demos in their own way, so you need the very mod (and also maybe version) that recorded this demo to be able to watch it. Eg: if it was recorded with CPMA, use CPMA; if it was with ExcessivePlus, use ExcessivePlus; etc... Also, note that ExcessivePlus demos are more standard than other mod's when recording multiview demos, so you may be able to playback an ExcessivePlus demo without the mod, but it will be buggy.
About privacy and server-side demosEdit
Since server-side demos have access to every player's data, privacy issues can be raised, notably chat messages, IP address and GUID.
In all the implementations cited above, these issues should not happen:
- IP address should not be recorded
- GUID should not be recorded (warning: TheDoctor's patch name the demo file with the client's GUID, so be careful to rename them before giving them publicly)
- Tell chats and teamchats should not be recorded
- VoIP should not be recorded
- Sensible admin/rcon cvar changes (such as passwords) should not be recorded (not to be confused with rcon commands such as say which should be recorded)
If a developer would want to make another implementation of this feature, he should be careful to filter sensible data at recording and not at replaying (because then it would be easy to avoid the filtering by editing the code).
Additional tools Edit
There are some tools that allow to do advanced tasks.
- Quake 3 Moviemaker's Edition (a.k.a. Q3MME). This tool allows special camera options and more features. It is useful to create videos. You can find it here. It is for Quake III Arena, but here you can find some instructions about how to make it work with OpenArena; and here there is an alternative method. You can also find it on Sourceforge (latest binary version should be here), with its source code under GPLv2 (a .rar archive with sources, dated year 2011, is available here).
- OpenArena Movie Maker's Edition (a.k.a. OAmme or OAMME) is derived from Q3MME, adapted to fit OpenArena. Tool by Biox1dE: oamme-v4.7z (1.5 MB) - wolfcamOA-0.6.2.zip - bioWolfcam.cfg.
- GamersTV (a.k.a. GTV) allows to "retransmit" online matches, to allow more people to spectate them. It is for Quake III Arena (you can find it here), but it has been created an "hacked" version that works with OpenArena: you can find it here (version 0.9.9). The OA version is included, with other server management tools, in "Open Arena Server PowerPack v1.1.2": download link. It is possible to automate the launching and connection of GTV using oamps.sh, an automatic server management tool for OpenArena.
- TheDoctor's server-side demos patch allows to record server-side demos automatically, one demo is recorded per player and all these demos are standard so that they can be replayed by client without any patch. You can find it here or here . Note: recording only activates for a player when this player reach a certain score threshold (0.9*fraglimit), so that it may happen that not all clients may be recorded.
- GrosBedo's full server-side demos patch allows to record full server-side demos, one per game, which when replayed allows to freefly and change the view during the demo without quitting. Clients also need to patch their engine to be able to replay these demos. This patch also works with mods. You can find it here or here.
- Makeavideo - How to create a video, in short.
- ↑ Timescale is usually a read-only variable, but you can change it freely during demo playback. It is possible to change timescale during actual game only if loading a map with devmap <mapname> (cheats enabled).