Pages: 1 ... 5 6 [7]
  Print  
Author Topic: The server-side demos thread, rebooted!  (Read 193491 times)
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #150 on: March 23, 2012, 06:17:22 AM »

Thank you. But I dont know if I will be able to do any test before sunday...
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #151 on: March 23, 2012, 11:27:33 AM »

@Gig: no problem, don't be sorry, I am glad that at least someone plan to try this patch :p

NEWS: Finalized the code, and ported to OA+ioquake3 r2224. Unified diff patchs are provided. This is the same code for OA 0.8.8 and the hybrid OA 0.8.8 + ioquake3.

You can find the OA 0.8.8 server-side demos project here (branch "master"):
https://github.com/lrq3000/openarena_engine_serversidedemos

And the OA 0.8.8+ioquake3 r2224 server-side demos project here (branch "latest"):
https://github.com/lrq3000/openarena_engine_serversidedemos/tree/latest

Unified patchs for both branches and win32 binaries and a few demo examples can be found here:
https://github.com/lrq3000/openarena_engine_serversidedemos/downloads

I consider this project finished. I may update it if I get some feedback, but I won't promise any precise date.

As a side note, I have tested a bit the storage efficiency, it seems server-side demos produced by this patch are about nbplayers times the size of a standard demo. In my test, you can expect 125 KB/min per player. For a real game of 10 players (and no spectators) and 20 min timelimit, if we extrapolate from this observation, we should expect 125*10*20 = 25 MB for one demo. However, real tests on production servers should be performed in order to get a better estimate of the storage consumption.

My warm thank's go to all the people who participated in this thread and tried to help me in one way or another, especially sago and grey matter who both were very patient with me.
« Last Edit: March 24, 2012, 03:22:59 AM by GrosBedo » Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #152 on: March 23, 2012, 02:25:58 PM »

Opening to the future

I have taken a look at a possible alternative way of making such a patch, based on TheDoctor's approach.

At first, I thought that the approach was different and based on flux. But in fact, it's the exact same approach as Amanieu's, the difference being that TheDoctor's patch rely on client-side facilities to replay demos (so it NEEDS a client to replay a demo), while Amanieu's code didn't: it has its very own replaying facility server-side.

But this approach is still interesting.

More details follow.

----

TheDoctor's patch simply dumps the data packets sent to clients.

Then, the client can replay the demo by using the standard demo facility (because this is how standard demos are made: from network packets dumps).

From cl_parse.c, CL_ParseServerMessage() function:

Code:
//
// parse the message
//
while ( 1 ) {
if ( msg->readcount > msg->cursize ) {
Com_Error (ERR_DROP,"CL_ParseServerMessage: read past end of server message");
break;
}

cmd = MSG_ReadByte( msg );

if (cmd == svc_EOF) {
SHOWNET( msg, "END OF MESSAGE" );
break;
}

if ( cl_shownet->integer >= 2 ) {
if ( (cmd < 0) || (!svc_strings[cmd]) ) {
Com_Printf( "%3i:BAD CMD %i\n", msg->readcount-1, cmd );
} else {
SHOWNET( msg, svc_strings[cmd] );
}
}

// other commands
switch ( cmd ) {
default:
Com_Error (ERR_DROP,"CL_ParseServerMessage: Illegible server message");
break;
case svc_nop:
break;
case svc_serverCommand:
CL_ParseCommandString( msg );
break;
case svc_gamestate:
CL_ParseGamestate( msg );
break;
case svc_snapshot:
CL_ParseSnapshot( msg );
break;
case svc_download:
CL_ParseDownload( msg );
break;
case svc_voip:
#ifdef USE_VOIP
CL_ParseVoip( msg );
#endif
break;
}
}

This is the code that parse the packets and replay a standard demo.

On the other hand, Amanieu's approach was to dump the events, not the data packets. This is more insightful in our case, because this is what allows to replay them.

If we only dump the data packets, there is absolutely no facility provided server-side to replay them (because they are designed to be an update specific to the target client), so to fix that we would either need to include client/ files to access the functions, or copy/mimic them, which is neither satisfying.

But if we dump events, we have a broad range of functions provided in the server/ files to play these events. Hence the approach of Amanieu.

-----

All that is to say that it's currently not possible to produce multi-view server-side demos with TheDoctor's approach since there's no replaying facility and data packets are designed per client. Everything is replayed client-side, so there's no way for example to allow for freeflying spectators since when you play the demo you are in the "eye of the beholder".

However, I think there's some ways to tweak this approach and come to an "hybrid" approach that would overcome these limitations:

- make a replay facility server-side, by feeding real clients some fake packets containing the messages of a demo. This can easily be done by just reading a message from a demo and using SV_SendMessageToClient(client, &msg). What is harder is to prevent the server from sending conflicting data to clients (because the server will continue to send them the valid gamestate), without crashing the clients nor the server.

- instead of recording every client's flux separately, we could save them all in the same file and add an event "End of frame" which would allow to replay these packets at the right time (similarly to Amanieu's approach, see my patch).

- hook clientCommand and when the client send a "follow" or "follownext" command, the server would send them the flux of the democlient associated with the number. But it seems that FollowCycle (when you click your mouse button) is not catched this way, so it would be needed to edit the gamecode at least to allow the hooking of FollowCycle.

- to allow freeflying, spectators that are known to be freeflying right now would be sent just the entities states and player states. A gamecode hook would also be needed here, because I don't know of a way to know the state of a spectator (and who he is following) completely server-side, but from the gamecode it's easily available.


As you can see, this implementation would greatly outdo my current implementation in terms of performance, because everything would be computed client-side and not anymore server-side (even if my implementation is already pretty inexpensive on CPU since there's nearly no gamecode event, everything is simulated, no actions processing involved). However, it would not be possible to use it with mods (unless workarounds are found for the above problems).

Anyway I do think this approach could be very interesting for a GTV replacement, since it would allow to support a big crowd of players watching the same demo flux.

----

As a memo, here's the big picture of standard demo replaying client-side:
CL_SetCGameTime -> CL_ReadDemoMessage() -> CL_ParseServerMessage() parse the servers messages -> various parsing functions...

And how TheDoctor's patch write demo messages:
SV_SendClientSnapshot() -> SV_UpdateServerCommandsToClient() and SV_WriteSnapshotToClient() -> back to sendclientsnapshot -> SV_SendMessageToClient()

----

In summary, both patchs are very similar, except for where the demo events are processed: client-side for TheDoctor's, server-side for Amanieu's. And this is all where the problem resides in making a fully server-side demo but processed client-side: how to allow freefly and viewpoint change when everything is processed client-side?
« Last Edit: March 27, 2012, 07:23:49 AM by GrosBedo » Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #153 on: March 26, 2012, 04:14:18 PM »

I've finally been able to try 0.9.9.5 win32 binaries.
A quick try, but I have to tell you GREAT! A cake for you!  Smiley  Smiley  Smiley

A little thing I noticed:
Quote
sv_demoState : show the current demo state (0: none, 1: waiting to play a demo, 2: demo playback, 3: waiting to stop a demo, 4: demo recording)
... what is value 3 exactly? Why I saw it as 3 instead of 0 when I was not playing a serverside demo?

A question:
demo_play, demo_sercord, demo_stop... what about a "sv" in the name of those commands, to better distinguinsh them from standard demos commands?

PS: Why are there two .dll in the zip file?

PPS: Everyone around here should try that!  Smiley
Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #154 on: March 27, 2012, 03:21:56 AM »

Thank you Gig, Im quite happy it ran well for you too Cheesy

Quote
sv_demoState : show the current demo state (0: none, 1: waiting to play a demo, 2: demo playback, 3: waiting to stop a demo, 4: demo recording)
... what is value 3 exactly? Why I saw it as 3 instead of 0 when I was not playing a serverside demo?

This comes from qcommon/qshared.h :
Code:
typedef enum {
DS_NONE,

DS_WAITINGPLAYBACK, // demo will play after map_restart)
DS_PLAYBACK, // a demo is playing
DS_WAITINGSTOP, // demo is stopped but we must move clients over their normal slots

DS_RECORDING, // a demo is being recorded

DS_NUM_DEMO_STATES
} demoState_t;

In fact when replaying a serverside demo, real clients are moved by a certain offset, so that democlients can be assigned to their original slot (eg: if you were at slot 2 when recording the demo, when replaying this democlient will be at slot 2 too). This is necessary to make the simulation happening.

At the end of demo playback, the map is restarted to delete the democlients slots and move back the real clients, but to do this, we must have a way to know we are stopping the demo. Before, Amanieu's original patch used the "delay" command (a special command similar to "wait" but that doesn't freeze the game while it waits, it worked but was more unreliable because you couldn't know the exact time the map_restard took, and when clientside with no map_restard, it didn't work). Here I simply chose to add another demoState. In practice, you should never be able to see it because it should be really quick (just the time to restard the map).

So it is not normal that your demoState was stuck at 3, but I guess this is because you were playing your demo clientside, which does not happen to do a map_restart at the end of playback (it simply exits from the demo to the game main menu). This is not important and will not produce any bug, but thank's for pointing that, Ill fix that.

A question:
demo_play, demo_sercord, demo_stop... what about a "sv" in the name of those commands, to better distinguinsh them from standard demos commands?

There are no command in OA or ioquake with a prefix, only cvars do have prefix, so I just followed the spec. Also, demo_play and demo_stop do work clientside too, so prefixing sv would be a bit misleading, but for demo_record thats true. Dunno but this has to be given some thoughts. Maybe server_demo_* then?

PS: Why are there two .dll in the zip file?

These contain the OA renderers because of the new renderer modularity facility of the latest ioquake3. This is not related to my patch, undeadzy's patch also has them (see the OA 0.8.8 sources thread).
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #155 on: March 27, 2012, 06:12:50 AM »

Just a (stupid?) idea... What about using a different name for these demos, e.g. "full demos" instead of "serverside demos"... (still to better divide their commands from classic demos)?
E.g. fulldemo_play, fulldemo_stop, fulldemo_record?
« Last Edit: March 27, 2012, 07:45:19 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #156 on: March 27, 2012, 06:17:45 AM »

I like the idea, I think Ill do that, thank's Gig Smiley
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #157 on: March 27, 2012, 07:25:30 AM »

Since my computer crashed yesterday (along with losing all my data, don't trust Windows 7 profile folders nor chkdsk), I won't be able to update the code in a while.
Meanwhile, I've updated the wiki page about demos.
Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #158 on: March 27, 2012, 04:00:12 PM »

Hi! I'm not sure about this part:
(DO NOT LINK) h t t p s : / / openarena . wikia . com/wiki/Manual/Demos#About_privacy_and_server-side_demos
I feel I never actually heard real in-game OpenArena VoIP... but from what I read in ioquake3 documentation at the time... VoIP packets are recorded in standard demos... why should serverside demos be different? The same, I'm not sure, but probably standard demos record team chat... is it okay to change it for serverside demos?


Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #159 on: March 27, 2012, 04:27:00 PM »

Yes standard demos have absolutely no filtering (thus it records say, teamsay and tell), and it explicitely records VoIP packets. The difference is the intention of usage: a client recording a standard demo records it for himself, and if he release it publicly, he implicitly consent to make public all the data contained inside the demo.

On the other hand, a server-side demo is recorded by a server administrator, and he cant know when releasing the demos publicly if all the clients consent to make these private data public. So the best thing to do is to avoid the recording of the sensible data.

Also, server-side demos potentially contain more sensible datas than standard demos, such as IP and GUID (I cant check the code right now but I think I can remember standard demos do not record these datas). Also the server has access to ALL IPs and GUIDs, so disclosing them could be very dangerous for clients (eg: hacking...).

PS: OA in-game VoIP works, I have tested it Wink
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #160 on: March 28, 2012, 02:05:34 PM »

Ive given another thought about the alternative hybrid approach, and I think it's possible to overcome some of the limitations:

1)
- make a replay facility server-side, by feeding real clients some fake packets containing the messages of a demo. This can easily be done by just reading a message from a demo and using SV_SendMessageToClient(client, &msg). What is harder is to prevent the server from sending conflicting data to clients (because the server will continue to send them the valid gamestate), without crashing the clients nor the server.

Easy to be done: at replaying, we just have to use SV_SendMessageToClient(client, &msg). Both are already recorded in TheDoctor's patch.

And to avoid the interference of the engine, we simple impose a condition in SV_SendClientSnapshot() to call SV_SendMessageToClient() only if we are not replaying a demo (because if were replaying a demo, we will directly call SV_SendMessageToClient() in our demo loop).

2)
- instead of recording every client's flux separately, we could save them all in the same file and add an event "End of frame" which would allow to replay these packets at the right time (similarly to Amanieu's approach, see my patch).

As I said, TheDoctor's patch already records the messages, you then just have at each end of frame (at the end of SV_Frame(), see my current implementation) to record an "_endFrame" marker. This way, all messages will just be recorded when they are made by the engine, and we just add a marker so that at replaying we can know that we are changing frame.

To replay, we make a simple loop to process and send all demo messages (for the current frame) until we hit the _endFrame marker, then we exit the demo playback loop until next SV_Frame() iteration.

3)
- hook clientCommand and when the client send a "follow" or "follownext" command, the server would send them the flux of the democlient associated with the number. But it seems that FollowCycle (when you click your mouse button) is not catched this way, so it would be needed to edit the gamecode at least to allow the hooking of FollowCycle.

This one is tricky but should be possible and fairly easy to implement if done right.

Cmd_FollowCycle_f is in fact triggered in two way: either with follownext or followprev clientCommands, or either by just clicking the mouse button (which can be seen in the usercmd_t packets).

Code:
// game commands

  { "follow", CMD_NOTEAM, Cmd_Follow_f },
  { "follownext", CMD_NOTEAM, Cmd_FollowCycle_f },
  { "followprev", CMD_NOTEAM, Cmd_FollowCycle_f },

Code:
/*
=================
SpectatorThink
=================
*/
void SpectatorThink( gentity_t *ent, usercmd_t *ucmd ) {
...
client->oldbuttons = client->buttons;
client->buttons = ucmd->buttons;

 if ( ( client->buttons & BUTTON_ATTACK ) && ! ( client->oldbuttons & BUTTON_ATTACK ) ) {
Cmd_FollowCycle_f( ent );
}
...
}

This is a standard behaviour for all ioquake3 based game, so we can safely assume that clicking the button when spectator will always result in changing the viewpoint.

The usercmd_t packets are also available from the engine, and also we can access playerState_t->pm_flags.

Here's the idea is to basically to reproduce the behaviour of SpectatorThink() and Cmd_FollowCycle_f() in the engine instead of the gamecode, by just detecting when BUTTON_ATTACK is pressed while the client is a spectator (and it should always be in a demo playback, so this is optional).

But there will be some challenges:

- SpectatorThink(): detecting if the client want to change the viewpoint and maintain an array that says for all spectators who they are watching. This should be done at the beginning of any frame prior to sending demo messages to assign all spectators to the right democlient in case of a change.

- Cmd_FollowCycle_f(): to find the next democlient in the list, to achieve that we would need to maintain an array of the democlients indexes at any time. A non-empty configstring could be used to check that the democlient was active?
Note that the list would be needed anyway for "follow" to work, because we must make sure that we have a democlients that can be watched with the specified id.


4)
- to allow freeflying, spectators that are known to be freeflying right now would be sent just the entities states and player states. A gamecode hook would also be needed here, because I don't know of a way to know the state of a spectator (and who he is following) completely server-side, but from the gamecode it's easily available.

This one is HARD. I don't know even if it's possible to achieve it. Maybe it will be impossible, or just too easy to believe (because there's a chance that after step 3 is done, freeflying may be totally managed by the gamecode without having to change anything in the engine).

I explain: the problem here is not to allow for freeflying, as I wrote we just have to send the entities delta messages (update messages), and the client will just draw them and will be able to freefly around. The problem is to detect when the spectator wants to freefly.

To detail further, let me show you the code that allows to switch from following to freeflying (which is a call to StopFollowing()):
Code:
/*
=================
SpectatorThink
=================
*/
void SpectatorThink( gentity_t *ent, usercmd_t *ucmd ) {
...

if ( ( client->buttons & BUTTON_USE_HOLDABLE ) && ! ( client->oldbuttons & BUTTON_USE_HOLDABLE ) ) {
if ( ( g_gametype.integer == GT_ELIMINATION || g_gametype.integer == GT_CTF_ELIMINATION) &&
                g_elimination_lockspectator.integer>1 &&
                ent->client->sess.sessionTeam != TEAM_SPECTATOR ) {
                    return;
                }
StopFollowing(ent);
}
...
}

At first, you could think "well, why can't we use the same trick as in step 3 and detect when BUTTON_USE_HOLDABLE is pressed?"

Answer: because this is not a native behaviour of ioquake3. Ioquake3 does not even have any way to go to freefly once you've followed someone, except from joining the Spectator team again. So this behaviour was introduced in OpenArena.
Also, mods can further modify this behaviour. For example, ExcessivePlus does not go from Following directly to Freefly, but from Following -> Third-person view (Track Cam) -> TV View -> Freeflying.

Anyway, we could still implement this feature this way, by detecting if BUTTON_USE_HOLDABLE is pressed and then just sending him the entities states (and stopping to send him the democlient messages he was previously following), but this is not satisfying if you want to be faithful to the original way mods have made their spectating work. But this is without any doubt the easiest way to do it.

Now let's take a look on another way to do that. Let's see the code of StopFollowing():
Code:
/*
=================
StopFollowing

If the client being followed leaves the game, or you just want to drop
to free floating spectator mode
=================
*/
void StopFollowing( gentity_t *ent ) {
ent->client->ps.persistant[ PERS_TEAM ] = TEAM_SPECTATOR;
ent->client->sess.sessionTeam = TEAM_SPECTATOR;
ent->client->sess.spectatorState = SPECTATOR_FREE;
ent->client->ps.pm_flags &= ~PMF_FOLLOW;
ent->r.svFlags &= ~SVF_BOT;
ent->client->ps.clientNum = ent - g_entities;
}

As you can see, there's a playerState_t pm_flags PMF_FOLLOW that gets removed. Also the ps.clientNum gets changed too.

So a good way to do this would maybe be by checking the state of the pm_flags PMF_FOLLOW, but this would require that the gamecode would set it, which is not certain since the democlients do not exist on the server with this implementation. So the PMF_FOLLOW flag may not even be set.
Maybe we can then set PMF_FOLLOW flag by ourselves at demo playback in our functions made at step 3, and then the gamecode would be now able to call StopFollowing()? This is something to be explored...

--------------------------

So I now think this implementation could be pretty easily done. However, it may not be possible to get a satisfyingly working implementation of the Freeflying feature, but it would be posible to allow for follow switching (multiview) without any problem for sure.

I really do think this path should be explored. I currently have no time to dedicate to make a prototype of this implementation, but if someone out there is interested, I can give a hand and lend some of my knowledge.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #161 on: June 28, 2012, 10:26:16 AM »

New server-side demo patch for Urban Terror 4.x, based on AlphaIoquake3 patch (cited in the first post of this thread) with a few enhancements:

http://www.urbanterror.info/forums/topic/28657-server-side-demo-recording/

Base patch: https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/b28aaea62ae1543828b71aaf6ff94afdd9463014

Incremental fixes:
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/b0d0f70110096e476a1f1836ddeda557a9e96bc5
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/384d356487d120c37ce4fbff1e1ed38f7d1dea83
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/669c5b2d2c6adb956b6415b3b11dfbde13e505a7
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/0d7185175aafc798eb12ef33916916035f182ae6
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/863f36d115f18bc64c87cbd6b1c1b9eafac3ca68
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/b49fa4f63a31a9e781ca3f5547162c9956db1104
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/90cf8a4616e5b17240b3668aa120802715f2102e
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/24512a775f7a177a79081d68b8c89cfb80ca3638
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/d0bf31ded108b6894ab61a8edd7e1f2c022614a6
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/2ac2562006ce2193170e0a25708f312b9ecf803d
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/7a43630bfa72d649d99c4883e26fbbddffd68f8e
https://github.com/Barbatos/ioq3-for-UrbanTerror-4/commit/0494025b74800cd7f99228bcc7708e16795f1b85

Note: it seems to suffer from the same advantages and issues as the original patch: demos produced are standard (no need for client to patch to read the demos), but the admin has to issue a command to record any subsequent player joining after the demo has started recording. There is a workaround by using an external bot (B3):
http://www.urbanterror.info/forums/topic/28665-urt-serverside-demo-recording-bigbrotherbot-plugin/
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #162 on: March 11, 2013, 09:46:26 AM »

The patch was updated, now it works with OA 0.8.8 and even the very latest ioquake3 (on github).

I also have rebased the patch, so that now the commits are clearly at the top of the commits graph (thus it is now very easy to separate the ioquake3 changes, then on top the openarena_engine changes, and then at the very top the serverside demos commits).

I also have fixed the memory leaks, and the patch is currently being thoroughly used on the OAC servers, with no memory leaks problem anymore.

Old server-side demos are still compatible with the new release on github (and will normally always be thank's to sv_demoTolerant facility - but here you don't even need that, the latest changes are totally compatible).

However, there is one last problem: dynamic movers (like the hidden door on Kaos2) produce a crash when playing back the demo.

I will try to fix that last problem later, or just try to make the alternative patch I've been talking about in this thread (replaying the net messages instead of entities positions).
Logged
Danfun64
Nub


Cakes -1
Posts: 29


« Reply #163 on: December 05, 2015, 04:37:19 PM »

Sorry for bumping, but I have no idea how to rebase the serverside engine with the official engine.git. The automatic rebasing failed, and the instructions for manually rebasing confuse me. The fact that I am not a programmer doesn't help matters. Any ideas?
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #164 on: December 06, 2015, 05:33:10 AM »

Sorry for bumping, but I have no idea how to rebase the serverside engine with the official engine.git. The automatic rebasing failed, and the instructions for manually rebasing confuse me. The fact that I am not a programmer doesn't help matters. Any ideas?

Sorry Dan, I don't have the time to rebase and update the git history, and rebasing is indeed quite tricky (I'm not even sure I'll be able to do it by myself, I'll probably have to spend several days to get it done correctly).

However, if you just want to compile a binary for the latest official engine.git, there is probably an easier way, you'll loose the git history, but it will work: you can manually copy the bits of codes that were added into the engine by looking at the diff file, that I reuploaded here:

https://github.com/lrq3000/openarena_engine_serversidedemos/releases/tag/v0.9.9.5

Indeed, the server-side demos facility has been modularized as much as possible, to almost all the logic is managed by the files sv_demo.c and sv_demo_ext.c, so first you can just copy those two files right away onto the official engine.git. Then, what remains is to copy all the bits and codes that were added into the other files inside the server/ folder to implement various callbacks and variables definitions so that sv_demo.c and sv_demo_ext.c are called correctly by the engine. To do that, just look in the diff file, and copy the code into the corresponding files (the context will show you where to place those bits of codes, sometimes the placement is important, sometimes not, so I advise you to try to do the placement right).

This should not be too difficult to do. If you achieve that, please don't forget to post a link to your git repo, this may interest other developpers Smiley
Logged
Danfun64
Nub


Cakes -1
Posts: 29


« Reply #165 on: December 06, 2015, 07:00:23 PM »

There seems to be several patch files that I could use. I don't know the difference between "ioquake3-r2224-delaypatch.zip", "rcontellpatch-engine-r28.zip", "serverside-demo-event-entity-patch_v0.9.9.4.patch.zip", and "serverside-demo-patch-oa.ioquake3-r2224_v0.9.9.5.patch.zip".

What do you recommend?

edit: Maybe it's ignorance, but I find it odd that the serverside patch doesn't properly record the first person view of each player. At least the patch is open source, which Excessive Plus isn't.
« Last Edit: December 06, 2015, 07:50:53 PM by Danfun64 » Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #166 on: December 09, 2015, 03:56:52 AM »

@Danfun64: Use either "serverside-demo-event-entity-patch_v0.9.9.4.patch.zip" or "serverside-demo-patch-oa.ioquake3-r2224_v0.9.9.5.patch.zip", they are the same patch but against different versions of the OA engine. The other patchs are for other functionalities that should now be included in the latest OA engine since a long time.

What do you mean by "the patch doesn't properly record the first person view of each player"? Because the patch does that, and more: it records the whole gamestate of every players, items and games data, and replays them when you replay the demo. There are only two missing features compared to E+ demos: it doesn't fully record movable objects such as platforms (due to a limitation of the accessible fields in the engine, this begs for a fix but I'm not sure how), and it doesn't replay the delag (which is possible to do, E+ does it).
« Last Edit: December 09, 2015, 04:00:14 AM by GrosBedo » Logged
Danfun64
Nub


Cakes -1
Posts: 29


« Reply #167 on: December 10, 2015, 10:25:24 PM »

How do I apply the patch? Do I have to rename the engine source directory?
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #168 on: December 12, 2015, 06:25:07 AM »

This is simply a diff unified patch, you can apply it using the standard Linux tools (you need to apply on the whole engine source directory):

http://stackoverflow.com/a/9982282/1121352

However, since you want to apply it on a different version of the engine than the one the patch has been compiled against, I don't think it will work (maybe there are tools to do that? You may try to google search), so you will probably have to manually copy/paste the code from the diff patch to the correct places in the engine source code.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #169 on: December 12, 2015, 06:31:40 AM »

And if you are on Windows and you need a diff file viewer, you can install TortoiseGit, it comes with TortoiseGitUDiff.
Logged
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #170 on: March 04, 2017, 11:24:20 AM »

REJOICE! BIG NEWS! (this is not a clickbait Wink ): server-side demos for OpenArena/ioquake3 are now a reality.

1. All (big) issues have been fixed in my server-side demos patch: movers are correctly replayed, and the patch has been tested for years on my servers (and is being used for a new E+ competition), it worked without any issue. This leads to the release of the first stable release v1.0.0, you can grab it here: https://github.com/lrq3000/openarena_engine_serversidedemos/releases

2. Another developper implemented the snapshot-replay approach, an alternative approach to my patch. This implements something more akin to a multiview demo than a real freeflying server side demo, but it's also completely server side and mod-agnostic! This is like TheDoctor's patch, but it saves all demos in one file instead of one demo per player, and it has some more functionalities. To grab the diff patch, go here: http://edawn-mod.org/forum/viewtopic.php?f=5&t=7 (mirror here) and the commands/cvars are here: http://edawn-mod.org/binaries/quake3e-mv.txt

3. My patch is also available for the latest ioquake3 and has been submitted as a pull request.

So that's pretty much the end of this quite long story, with a happy ending Smiley These patchs could be used to recreate a GTV replacement, a new adventure!

« Last Edit: March 04, 2017, 11:34:34 AM by GrosBedo » Logged
Gig
In the year 3000
***

Cakes 45
Posts: 4394


WWW
« Reply #171 on: March 06, 2017, 03:30:55 AM »

Ohh!!! Quite interesting!!!  Smiley
I was wondering what happened with the development of this stuff...

Let's also say that more infos (including usage infos and "todo") are available here:
https://github.com/lrq3000/openarena_engine_serversidedemos

About including it in OA3, I don't know if Fromhell is going to sync anything more from ioquake3 repo. So it may be necessary to manually pull it to OA3 engine repo... maybe after getting some feedback from ioquake3 guys to make some fixes if necessary. Wink

« Last Edit: March 06, 2017, 03:59:26 AM by Gig » Logged

I never want to be aggressive, offensive or ironic with my posts. If you find something offending in my posts, read them again searching for a different mood there. If you still see something bad with them, please ask me infos. I can be wrong at times, but I never want to upset anyone.
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #172 on: March 07, 2017, 04:13:19 PM »

Thanks Gig, nice to see you Cheesy

No I don't expect this to be merged in OA3, since it's really only useful to competitive server administrators (so only a very few subset of administrators, which are themselves a very few subset of players), but at least this solution now exists and admins can compile the patch themselves Smiley

But it should be possible to patch OA3 quite easily, I saw that OA3 is now almost completely synced to the latest ioq3, and the latest patch is now also made for ioq3:

https://github.com/lrq3000/ioq3/tree/server-side-demo
Logged
fromhell
Administrator
GET A LIFE!
**********

Cakes 35
Posts: 14520



WWW
« Reply #173 on: March 07, 2017, 07:53:09 PM »

FYI it's not synced to the latest because that SDL2 implementation commit regresses a bunch of things on Windows and most of the changes in the past 2 years is in regards to the GL2 renderer we don't use nor do plan to use.  so for that reason it should patch to the OA3 tree fine
« Last Edit: March 07, 2017, 08:06:24 PM by fromhell » Logged

asking when OA3 will be done won't get OA3 done.
Progress of OA3 currently occurs behind closed doors alone

I do not provide technical support either.

new code development on github
GrosBedo
Member


Cakes 20
Posts: 710


« Reply #174 on: March 10, 2017, 05:03:04 AM »

Thank you fromhell for the info, this explains why I could easily port the patch to the latest ioq3 then, and so it should also apply to OA3 easily Smiley

BTW I just discovered that ET-Legacy is using the patch since years, and they fixed a few things. Might be interesting to merge in these fixes, I'll have a look:

* https://dev.etlegacy.com/issues/278
* https://dev.etlegacy.com/projects/etlegacy/wiki/Changelog#Server-7

PS: you're right not to use GL2 renderer, it's awfully slow and incompatible with most hardwares (mine included, I had to disable it just to be able to launch the game).
Logged
Pages: 1 ... 5 6 [7]
  Print  
 
Jump to: