Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001777Zandronum[All Projects] Suggestionpublic2014-04-10 19:082019-06-07 20:04
ReporterDusk 
Assigned ToDusk 
PrioritynormalSeveritymajorReproducibilityN/A
StatusnewResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001777: Serverside demos
DescriptionSo I've been doodling about the possibility of serverside demos. I still want to do them and here's my thoughts about it

The serverside demo will largely be like the clientside demo, with a few differences. It will begin when the first player enters the server and ends when the last player leaves. The server doesn't need to authenticate itself (duh) so the demo just starts off with a snapshot of the level followed by action.

The bulk of the demo will consist of every server command that is sent that does not have SVCF_ONLYTHISCLIENT set. The gist of the idea is to have an 'imaginary client' 'connected', like a big brother really, thus whatever is broadcasted needs to be recorded. amirite

The demo needs a constant consoleplayer, which the server lacks. Thus, the last player slot, i.e. index 63, will be reserved for use as the serverside-demo consoleplayer. This means sv_maxplayers will be capped to 63 maximum while the server records a demo. Not even the 'localhost hack' thing is to be able to get the 64th slot.

The userinfo of the consoleplayer I haven't thought out yet, but not a lot matters other than the name. I'll probably use "<server>" for the purpose as it's reserved like that. The consoleplayer will spectate at all times and will just sit and idle.

The file extension of the demo will be ".svd" to distinguish it from clientside demos, however the format is the same and the extension only serves for quick identification. For the actual distinguishment of the demo code-wise, I'll add a byte into the header to dictate whether it's a serverside or a clientside demo. zcinema will be updated accordingly.
Additional InformationIssue 0001694 should be considered first because if we don't implement it sv_commands.cpp needs to be updated throughly for NetCommand. I don't want to do that if protobuffers are implemented though I will not implement them if it comes down to that, it'll be simpler for me to just netcommandify stuff.
Attached Files

- Relationships
parent of 0001793closedDusk Conversion of sv_commands.cpp to NetCommand 

-  Notes
User avatar (0008596)
Dusk (developer)
2014-04-17 11:42

 Now that the netcommandification has been done I'm working on implementing this. I got stuff done last night but currently am struggling getting it to actually work...
User avatar (0008597)
Torr Samaho (administrator)
2014-04-17 17:31

 BTW: Why do you need a constant consoleplayer? Can't you do something like I did for the free spectate mode in client side demos?
User avatar (0008599)
Dusk (developer)
2014-04-17 17:38

 Even with free spectate mode there is still the recorder of the demo as the consoleplayer. With serverside demos there is no constant consoleplayer because the server, which records the demo, doesn't have one.
User avatar (0008601)
Torr Samaho (administrator)
2014-04-17 18:38

 Sure, but I'm wondering for which technical aspect you need a constant consoleplayer.
User avatar (0008602)
Dusk (developer)
2014-04-17 18:57

 I can't really feed Zandronum an invalid consoleplayer while playing back a demo, can I? Some consoleplayer must exist and the codebase assumes it's constant.
User avatar (0008604)
Torr Samaho (administrator)
2014-04-17 20:18

 The server can handle the whole game logic without a console player, so I think that one should be able to make the demo playback work without a true console player. From the top of my head the only thing I know that is necessary to be valid (without changing large parts of the code) is players[consoleplayer].camera.

Changing players[MAXPLAYERS] to players[MAXPLAYERS+1], setting consoleplayer to MAXPLAYERS and putting a valid camera (see demo_spectatefreely) in players[consoleplayer].camera could be a good start. But you can also first try to get this to work your proposed reserved consoleplayer slot and we worry about getting rid of the reserved slot later.
User avatar (0009081)
Watermelon (developer)
2014-06-11 17:02

 I'm assuming each map change would cut a demo off and start a new one?

The current way we make demos is painful. All other ports for client demos are fragmented per each map.
User avatar (0009092)
Dusk (developer)
2014-06-11 18:39

 I was thinking about starting a demo when a server becomes populated and ending it when the server becomes full.

The big problem here is that all this defensive coding that we've done in Zandronum is biting me in the ass here. A lot of our safety checks locks the serverside demo recorder out from a lot of functions. I don't know what to do here.
User avatar (0009094)
Watermelon (developer)
2014-06-11 18:53

 I wonder then if it's worth forcing -1 player for servers that want to record serverside demos? Then allocate a player?
Updating everything to allow for serverside demos sounds like a major task
User avatar (0009148)
ZzZombo (reporter)
2014-06-12 17:23

 Why you can't just save all client commands into a file and then read it back w/ proper settings like map, CVARs, etc, emulating the server getting those commands from real players?
User avatar (0009177)
Dusk (developer)
2014-06-12 21:50
edited on: 2014-06-12 21:50
Quote from ZzZombo
just
User avatar (0009183)
ZzZombo (reporter)
2014-06-13 13:03

 I'm sorry?
Care to elaborate?

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: Absolute Zero WaTaKiD Razgriz Argentum capodecima AlexMax Korshun Michaelis
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2014-04-10 19:08 Dusk New Issue
2014-04-10 19:08 Dusk Relationship added related to 0001694
2014-04-10 19:08 Dusk Summary Serverside demos (implementation draft) => RFC: Serverside demos (implementation draft)
2014-04-10 19:10 Dusk Description Updated View Revisions
2014-04-10 19:10 Dusk Status new => feedback
2014-04-11 14:52 Dusk Additional Information Updated View Revisions
2014-04-17 11:42 Dusk Note Added: 0008596
2014-04-17 11:42 Dusk Status feedback => new
2014-04-17 11:42 Dusk Assigned To => Dusk
2014-04-17 11:42 Dusk Status new => assigned
2014-04-17 11:42 Dusk Description Updated View Revisions
2014-04-17 11:42 Dusk Additional Information Updated View Revisions
2014-04-17 11:42 Dusk Summary RFC: Serverside demos (implementation draft) => Serverside demos
2014-04-17 17:31 Torr Samaho Note Added: 0008597
2014-04-17 17:38 Dusk Note Added: 0008599
2014-04-17 18:38 Torr Samaho Note Added: 0008601
2014-04-17 18:57 Dusk Note Added: 0008602
2014-04-17 20:18 Torr Samaho Note Added: 0008604
2014-05-04 02:16 Dusk Relationship added child of 0001793
2014-05-04 02:16 Dusk Relationship replaced parent of 0001793
2014-05-04 02:16 Dusk Relationship deleted related to 0001694
2014-06-11 17:02 Watermelon Note Added: 0009081
2014-06-11 18:39 Dusk Note Added: 0009092
2014-06-11 18:53 Watermelon Note Added: 0009094
2014-06-12 17:23 ZzZombo Note Added: 0009148
2014-06-12 21:50 Dusk Note Added: 0009177
2014-06-12 21:50 Dusk Note Edited: 0009177 View Revisions
2014-06-13 13:03 ZzZombo Note Added: 0009183
2019-06-04 21:54 Dusk Status assigned => new




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker